On-Premise Exchange Notes from MEC 2014

MEC 2014 was an educational event that provided great insights into all aspects of Exchange. If you missed the conference this article will cover learning aspects as they related to deploying Exchange On-Premise. Here are some of my takeaways from the conference on this topic.

New Products

Microsoft announced that they expect the next version of Exchange will be released sometime in 2015. As Office 365 continues to grow they are releasing new product options such as Clutter and People View to Office 365 customers first. They also indicated that they do expect these options will be added to Exchange On-premises; however, the timeframe was currently unknown.

What are my Server Roles?

Exchange 2013 at RTM only had two server deployment roles.  They were the CAS and mailbox role; however, with Exchange 2013 SP1 they have brought back the Edge Transport Role.  These roles are the same as what we have learned about in Exchange 2007 and Exchange 2010 with the exception of the CAS role.  The CAS role has been architected in a way that it will no longer perform any data rendering.  The CAS role will only provide authentication and proxy redirection.  Providing support for internet protocols, transport and unified messaging.  This includes HTTP, IMAP, POP, SMTP and the UM Call Router.  The Edge Transport Role (optional) and Mailbox role support the same functionalities as in the past (more information on the Edge Transport and its purpose).

The other role based recommendation; which is similar to Exchange 2010, is to run all of your roles on all of your servers.  For example, every Exchange server should have the CAS and Mailbox role installed on it.

IOPS and Affordable Disk

When considering moving from previous versions of Exchange to Exchange 2013, it should be noted that with each version there have been huge strides in IOPS performance gains.  For example, if you take a look at where we started with Exchange 2003 there has been a 93% reduction in IOPS from Exchange 2003 to Exchange 2013.  This allows for the ability to use more affordable disk for Exchange deployments.  The conference recommendation was to use 7.2K RPM SAS drives.  With this change it has just become more affordable to offer our users larger mailboxes without all the hassle.  In time this has the potential to us to fewer .pst files and in some cases the need to implement 3rd part archiving solutions will not be necessary.  Of course this depends on the reason you are implementing the 3rd party archive, but if the sole reason was moving data to more affordable disk then this problem is now solved.

Database Availability Group (DAG)

For deployments that require a certain level of redundancy and the use of a DAG with multiple databases you should be using JBOD configurations.  JBOD is just a bunch of disks without all the typically RAID configurations we have grown to know and love.  What we have learned is that the disk level of redundancy is not required when you use a DAG.  The database copies in a DAG provide the redundancy required.   The cost model with JBOD is also more affordable with the reduced IOPS requirements in Exchange 2013.  Lower performance drives will still provide the performance our users expect.  With Exchange 2013 we also gain the benefit of auto reseed of our databases instead of manual reseed and intelligence that allows for failover to a hot spare disk.

Client Connectivity

Other conference recommendations for On-Premises Exchange were to use RPC/HTTP for your Outlook connections.  In fact, regardless of the version of Exchange you are running on today a recommended pre-migration step for your full Outlook clients is to move them to RPC/HTTP.  This done in advance of your migrations will ensure that your users incur the least amount of impact during the migration. 
There was also information related to MAPI/HTTP; a new client protocol; that Microsoft has introduced in Exchange 2013.  My takeaways on this were that it was not advisable to skip over the step of moving to RPC/HTTP first.  Move to RPC/HTTP first for the most seamless end-user experience.  It was also recommended that we do not enable MAPI/HTTP while still connected to Legacy public folders, because all connectivity to them would be lost.

Other Recommendations

There were also some of the other Exchange On-premises related recommendations that were highlighted for your Exchange On-Premise designs.  There were discussions around use of 10GB NICs becoming the standard for network cards and datacenter configurations.  In the case where this is true our configurations no longer require a separate MAPI and Replication network in our design.  These can all run together on the same network.

Name Space Planning was also a topic of interest.  Microsoft has two models of thought due to the fact that many customers in previous versions of Exchange were using the same namespace for internal and external Exchange aspects.  For example, owa.company.com was the same name for inside and outside access to Outlook Web App.  In most cases this was adequate, but there were situations where this wasn’t.  By providing their customers with better information on how to handle namespaces it simplifies design, implementation and migration to newer versions of the product.  Here are the two models:

• Unbound Service Model:  Uses a single name space in two datacenters in an Active/Active DAG design.  User will function from either datacenter.  This is the recommended method.
• Bound Service Model:  Uses site specific name spaces with the datacenter configuration being Active/Passive binds the user mailbox to a preferred datacenter.  In this design the dag will failover to the other datacenter.  Functionality will be limited to interorganizational mail only until failback or other recovery methods can be invoked. 

Finally, for the best results with migration planning and co-existence make sure your Exchange version is at the latest available.  For example, for Exchange 2010 that would be SP3 with RU5.

Conclusion

My observations while at MEC were that while there is much hype around Office 365 and moving office related aspects to the cloud, Exchange On-Premise is still used very heavily within organizations.  The message they are sending is to keep implementations simple and they are working to create more solid guidance about best practices of their deployments than in the past.  This ensures that we are able to provide the best outcomes for our users.