In-Depth

Under the Hood of Exchange 2013: What's New

The upgrade to Redmond's flagship messaging platform includes a new Admin Center, compliance enhancements and architectural improvements.

Many IT pros have managed Microsoft Exchange Server since its inception. My own 15-year experience began with Exchange 5.5, launched in November 1997. One of the issues I addressed early on was using the Active Directory Connector (ADC) to connect Exchange 5.5 with Active Directory. I remember when Microsoft integrated native instant messaging into Exchange Server 2000, which it later pulled out in favor of its own server application that we now know as Lync.

I also recall the front-end, back-end deployment solutions with Exchange Server 2003. When Exchange Server 2007 arrived we saw five server roles and four high availability (HA) solutions using continuous replication. And with Exchange Server 2010 we saw those HA solutions merged down into one database availability group (DAG) solution. Because I've seen it all, I feel comfortable saying that, after spending several months evaluating the new Microsoft Exchange Server 2013, I'm blown away by the new features, which warrant the attention of anyone with an older release of the company's flagship e-mail platform. It all starts with new administration capabilities.

A New Admin Center
Exchange 2007 introduced the Exchange Management Console (EMC), a GUI that uses the Microsoft Management Console (MMC) format with Windows PowerShell commands driving all administrative actions. It also brought forth the Exchange Management Shell (EMS), offering an all- Windows PowerShell-driven command-line method of administration for Exchange. With Exchange Server 2010 we saw the return of the EMC and EMS, but Microsoft also added a Web-based version of GUI administration called the Exchange Control Panel (ECP). It was lame to start with, but Microsoft improved it with the first service pack and it was clear this would be the future of Exchange administration. So you can imagine my surprise when Microsoft removed the EMC in Exchange Server 2013, leaving only the Exchange Admin Center (EAC) in its place. (Note: Microsoft still provides the EMS as well.)

I also wasn't prepared for such a radical change in terms of layout for administration, with Features highlighted on the left column, tabs up at the top, and a Details pane to the right where the Actions pane is in an MMC console (see Figure 1). This is a dramatic move and takes some getting used to, especially because Microsoft decided to redesign everything in its new Windows UI experience, which many still call "Metro."


[Click on image for larger view.]
Figure 1. The new Exchange Admin Center.

I have to admit I truly hated the new EAC upon first glance at the MVP Summit in Redmond in early 2012. I said as much to the team. But it really grew on me. I like that I can use the browser settings to adjust the font and choose a more appealing one. I wish I could alter the color scheme because I find it -- like the Office 2013 Metro versions -- too bright and lacking in color. I do find breaking things into features is much better than the way it was in the EMC with things broken down by Organization, Servers and Recipients.

One of the best things about the new EAC is that it's Web-based and fully functional (unlike the ECP in Exchange Server 2010), so you can use URLs to access it both internally and externally -- as long as you have DNS configured and make sure the firewalls aren't blocking access. This is much better than having to install the MMC-based EMC on a system to manage your Exchange organization.

New (or Legacy) Server Role Architecture
I call the new Server Role Architecture "legacy" because it's extremely 2003-esque. Gone are the five server roles, replaced with the Client Access role and the Mailbox role. The Client Access role is made up of the Client Access server (CAS) role and some of the transport capabilities of the Hub Transport role. The Mailbox role consists of the Mailbox role, the Unified Messaging role and pieces of the Hub Transport role. The Edge Transport role is still available through Exchange Server 2010, but you'll have to wait and see if there will be an update at some point in the future. As of now, there's no Edge Transport server role in Exchange Server 2013.

Some have wondered why there was a change back to a front-end Client Access, back-end Mailbox solution. It actually goes back to the reason for the division of server roles in the first place. There were constraints -- notably CPU performance -- with the technology back in 2007 when the server role model was provided. As CPU horsepower increased and became less expensive, it became more reasonable to combine roles. In fact, for quite some time the direction from the Exchange team has been to perform typical deployments of Exchange Server 2010, which is where the three main roles (CAS, Mailbox and Hub Transport) are deployed together.

In addition to a reduction in roles down to two internal roles, there's a change in the role of Microsoft's RPC-based Messaging API (MAPI). Historically Outlook used two transport options for RPC traffic: HTTP or TCP. With Exchange 2013, all Outlook clients now connect using just RPC over HTTP, otherwise known as Outlook Anywhere. This adjustment might seem to make the client connection more convoluted, but it actually has several benefits. There's no longer a need for the RPC Client Access service on the CAS. As a result, there's a reduction in namespaces needed -- hence, you no longer need two for the RPC Client Access service for a site-resilient design. In fact, the overall minimal namespaces required drops from eight down to two, thanks to the many changes made.

A New Managed Store
What you may know as the Information Store process in legacy Exchange is now called the Managed Store, and is completely rewritten in C#. When you look at your processes you'll note that there are two: the Microsoft.Exchange.Store.Service and the Microsoft.Exchange.Store.Worker process. What's interesting about this change is -- along with several improvements that aid in improving resiliency and provide improved diagnostics to allow improvements going forward for the future iterations of the store -- the new Managed Store mounts each database with its own worker process. Each mount request spins up a new worker process, so a failure on the part of one process won't impact the other process or database, should it hang.

You can see a server that has multiple databases mounted and, therefore, multiple worker processes, although only one Store.Service process (Figure 2). Another important adjustment with the Managed Store is the inclusion of the FAST search engine, offered as an option in SharePoint 2010 and included with the new SharePoint 2013. The addition of FAST really enhances search and indexing.


[Click on image for larger view.]
Figure 2. The new Managed Store processes.

Compliance Enhancements
Exchange Server 2013 enhances all the existing features of 2010 by providing much better mailbox search through the In-Place eDiscovery and Hold feature, improved auditing, enhanced use of retention policies, in-place archiving, journal rules and more, all shown under the Compliance Management features in the EAC (Figure 3).


[Click on image for larger view.]
Figure 3. The Compliance Management feature set of tabs.

Through the new In-Place eDiscovery and Hold feature you can configure a mailbox search through all mailboxes or selected ones. You can focus on keywords, a date range, To and From, and message types through the search query. At the same time you can use the In-Place Hold feature to place content matching the search query in selected mailboxes on hold either indefinitely or for a specified number of days relative to their received date. This new In-Place Hold is recommended over Litigation Hold (aka Legal Hold) because it provides a more granular hold capability. With Legal Hold you place all items on hold indefinitely or until the hold is removed. With In-Place Hold you have the search query and can place multiple holds for a defined period, so there's a greater level of flexibility. Hence, Legal Hold has been -- as they say in Microsoft-speak -- deprecated. That means it's still available but the company recommends you move forward and use In-Place Hold.

Another new compliance feature is called Data Loss Prevention (DLP). DLP policies are based on the same principles as transport rules in that you have conditions, actions and exceptions. Using predefined templates you can quickly and easily enforce some key regulatory and business policy needs. You can also build your own rules or modify the templates.

Note that you can select a DLP policy and quickly enforce it to protect your organization from having people e-mail important information such as their Social Security numbers or credit-card numbers (see Figure 4). You can warn them of the danger or you can prevent them from sending it, depending on how strictly you wish to enforce the DLP policy.


[Click on image for larger view.]
Figure 4. The DLP policy template.

For a list of DLP policy templates supplied in Exchange Server 2013 click here.

Collaboration Mailboxes
Microsoft has also made major and minor enhancements to collaboration mailboxes. These include shared mailboxes, site mailboxes and Public Folders, which are now nested inside Public Folder mailboxes.

Shared mailboxes are not new to Exchange, and their purpose in allowing multiple users to read and respond to e-mails through delegated access hasn't changed. Exchange Server 2013 lets you easily create shared mailboxes right from within the EAC through the Recipients feature. The value is still the same in that you can have generic, common mailboxes that can be responded to by multiple individuals (which is great for departments or common e-mail types such as info@company.com or sales@company.com).

Site Mailboxes are new to Exchange Server 2013 and require a SharePoint 2013 server to create the mailbox properly. Essentially these mailboxes allow greater collaboration by keeping the e-mail portion of correspondence within Exchange storage and the document portion within SharePoint. This way, you can use Outlook (though only Outlook 2013) to view data stored in SharePoint, which allows for all the coauthoring and versioning features over those documents. There are some immediate drawbacks here in that you need SharePoint 2013 and Outlook 2013 to make use of these supposed Public Folder eradicators. However, if you already plan on having the latest 2013 solutions, you might find these to be a much better solution to the current division we seem to have regarding collaboration data between Exchange and SharePoint communication.

Microsoft has renamed Public Folders as Modern Public Folders (like DC Comics with the new 52 -- and, yes, you're a geek if you know exactly what I'm talking about), and they have become quite easy to use through the EAC. In times past you created a separate Public Folders database and established your Public Folders hierarchy. Then you set up additional Public Folders databases around your Exchange organization and established replicas of key folders that you wanted to place closer to people depending on their content and location.

With Modern Public Folders you no longer create a Public Folder database. You create a Public Folder mailbox and this mailbox goes into a mailbox database. You can then create Public Folders that reside within that mailbox. You can create more than one mailbox, although the first one retains the primary position in the hierarchy (see Figure 5). On the upside, you can take advantage of the built-in HA features through DAGs to ensure passive copies of your Public Folders structure. Unfortunately, you can't place replicas of the mailbox closer to people who are accessing that data. But unlike site mailboxes, you don't need SharePoint 2013, nor do you have to use Outlook 2013 to utilize these Modern Public Folders (see Figure 6).


[Click on image for larger view.]
Figure 5. Modern Public Folder mailboxes.



[Click on image for larger view.]
Figure 6. Public Folders.

Anti-Malware
Exchange Server 2010 has built-in anti-spam features that remain available in Exchange Server 2013. If you aren't using an Edge Transport server, you might want to enable these features using the Install-AntiSpamAgents.ps1 script to get them added to your Mailbox server. Once enabled, you can configure the Content Filter agent, the Sender ID agent, the Sender Filter agent, the Recipient Filter agent and the Protocol Analysis agent for sender reputation. One thing to note is that the anti-spam settings are no longer configurable through the UI, and require you to use the EMS to configure these agents once installed. Now, however, Exchange has built-in malware protection. There's a Protection feature in the EAC that leads to malware policies you can configure with configuration settings (see Figure 7).


[Click on image for larger view.]
Figure 7. Malware Detection Response settings.

Overall Assessment
We're not talking about a newcomer here. Exchange remains the primary solution for in-house, on-premises enterprise messaging. And Office 365 is gaining ground as a leading solution for hosted enterprise messaging as well. The question folks ask me with regard to Exchange Server 2013 always comes down to this: Should I move my organization toward it?

Here's the honest truth. If you're working with Exchange Server 2003 or earlier, migration to 2013 will be a bit of a pain. You'll need a third-party solution to help you do it as a single hop, or you'll need to make a hop to Exchange Server 2010 and then to 2013. It's easy to make the case for a move from Exchange Server 2003, because mainstream support is already over and extended support will end on April 8, 2014. So you have to move forward. The question is whether you move to 2010 and then to 2013, or straight to 2013 with a third-party tool.

There's support for a transition from Exchange Server 2007 and 2010, but 2007 requires a roll-up to make this happen and 2010 requires Service Pack 3. As of this writing, neither one of those things has been released yet. In the end, only you can determine if these new features are worth making the move. Every organization is different and the needs of each vary.

My own preference is for the latest and greatest technology. And I can honestly say Exchange Server 2013 has enough new features to warrant serious consideration.

Editor's note: This article was updated with the following corrections: Exchange 5.5. shipped November 1997, not February 1998. Also Microsoft did not remove MAPI from Exchange 2013, just the TCP support in the RPC transport that MAPI uses.  


comments powered by Disqus

Reader Comments:

Wed, Mar 20, 2013 DLP USA

Very informative article, thanks. The built-in Data Leakage Protection (DLP) feature is what attracted us to Exchange 2013. On the surface it looks great, but as we found in practice, the "DLP sensitive information types" (aka "Classification Definitions" when using the Exchange cmdlets) are highly deficient. These are the "rules" or "definitions" that are responsible for detecting sensitive data in the e-mail (ex. credit card number, social security number, etc). Nearly every sensitive type that we experimented with seemed to work on the surface, but failed in practice with high False Positives (falsely "detecting" things that are not actually there) and False Negatives (failed to detect sensitive data). Once deployed in small-scale production, the poor accuracy of these types caused frustration and required significant time from our admin (me!) to investigate them (especially since DLP reporting is not available in the on-prem version of Exchange 2013). If the DLP solution is not finding the right things, or if it's finding the wrong thing, what's the point!? We're currently evaluating a solution from Nucleuz ( http://www.nucleuz.com/ ) which so far (knock on wood) is performing much better and makes Microsoft's built-in DLP solution worthwhile. Maybe you can do a review of their stuff for a more elaborate comparison? Keep up the good work!

Tue, Feb 5, 2013 J. Peter Bruzzese

Scott, my dear friend, you have my email and sent me all of these points directly. No need to toss them out here, although I'm sure the readers do appreciate the added commentary. Not to worry, some of the points you mention will be adjusted. Other points are simply tomato/tomahto type issues that are bound to come up between a Senior TechNet writer and an outside tech journalist/Exchange MVP. We've battled over wording many times in the past and I'm always appreciative of your assistance but I disagree with some of your points here and TechNet actually disagrees with some of your points too. I've sent you those corrections (privately... as is appropriate between colleagues and Exchange brothers-in-arms). JPB

Sat, Feb 2, 2013 Scott Schnoll

You also state that "In addition to a reduction in roles down to two internal roles, there's also a change to client connectivity, and remote procedure call (RPC) is no longer supported." And then you state "To those who recall Redmond's evangelism of its Messaging API (MAPI), designed to enable message-oriented apps, that connectivity is now dead." These statements are not true, and I'm not sure why you make them. All MAPI traffic is RPC-based. Historically, Outlook clients have had two transport methods for RPC traffic available to them: RPC over TCP, and RPC over HTTP (aka Outlook Anywhere). In Exchange 2013, we removed the RPC over TCP option, leaving RPC over HTTP as the only connectivity method. This does not mean RPC is no longer supported. In fact, it is still used (e.g., we still make MAPI/RPC calls), we just encapsulate them in HTTP packets. You then state, "What you may know as the Information Store process in legacy Exchange is now called the Managed Store, and is completely rewritten in C#. When you look at your processes you'll note that there are two: the Microsoft.Exchange.Store.Service and the Microsoft.Exchange.Store.Worker process." These statements are confusing and misleading. First, the legacy Information Store process is not called the Managed Store. The Managed Store is in Exchange 2013 only. Second, as it uses the worker process model, you will have more than two processes running on all Mailbox servers that have more than one database mounted. You'll have a separate worker process for each database. Thus, if you have 40 mounted databases, you'll have 41 processes. You also state that "Another important adjustment with the Managed Store is the inclusion of the FAST search engine, offered as an option in SharePoint 2010 and included with the new SharePoint 2013. The addition of FAST really enhances search and indexing." We don't call it FAST any more (and haven't for some time). It's called Search Foundation, and it is not part of the Managed Store, but a separate search stack that integrates with transport and store. You also state in reference to modern public folders that "You can create more than one mailbox, although the first one retains the primary position in the hierarchy (see Figure 5)." There is no such thing as primary position in the hierarchy. There is the PF mailbox the has is the Primary Hierarchy (e.g., has the one writable copy) and there are other mailboxes that hold PF content which have read-only copies of the hierarchy (and are referred to as Secondary Hierarchy holders). It would be great if you could correct this article so you readers can get the most accurate information possible. Thanks!

Sat, Feb 2, 2013 Scott Schnoll

Hi Peter, I'd like to reiterate my offer to review your Exchange-related posts and articles before you publish them. I was reading your recent article, "Under the Hood of Exchange 2013: What's New", and I noticed several mistakes that should have been caught before going to print. For example, Exchange 5.5 was not launched in Feb 1998. Rather, it was released in November 1997. In addition, Exchange 2007 never had four HA solutions. It only had one: CCR. The other solutions are DR solutions, not HA. I'm happy to explain the difference between HA and DR if you have any questions about this. I'm not sure why you were surprised by the removal of EMC, especially since as an MVP and someone with access to the TAP, you should have been privy to our partner discussions as to why EMC was removed. Basically, it's a cloud-driven world, and EMC was not well-suited for the cloud. EAC and RPS are suited for the cloud, so they were carried forward. Like EMC, EAC is also built on POwerShell, so of course EMS is still included. The server role architecture is not 2003-esque. In fact, we didn't even start development on it until 2005, and it wasn't introduced until Exchange 2007. So I'm not sure how you can consider it 2003-esque. It's also worth noting that your description of the Exchange 2013 CAS role is not entirely accurate. The overwhelming majority of the functions of the Exchange 2007/2010 CAS were actually moved in the Exchange 2013 Mailbox role. The Exchange 2013 CAS is an all new, completely rewritten CAS, whose only similarities with the previous versions of CAS are that is provides a unified namespace and an authentication mechanism. It wasn't the lack of CPU performance in 2005-2007 that drove multi-role, but rather the lack of CPU scalability. There were no multi-core processors back then, so we scaled out the solution by creating the server roles. But it is not CPU that drove the consolidation of server roles down to 2 internal roles, but rather the need for simplicity and scale. In addition, we also wanted to add improvements to the network layer, increase hardware efficiency, introduce failure isolation, and introduce version interoperability. >

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.