In addition, OWA now supports "apps," which are basically tiny pieces of code that try to sense what you are doing within OWA and offer additional, context-sensitive functions. For example, if it sees you have received a message with driving directions, it offers to open up a map; or if it detects a task or an action from a message, it will add it to a Suggested Tasks list.
Developers will be able to create their own apps to bring even more functionality to OWA. These apps will live inside Exchange's "mailbox store" for each user and will be independent of the specific version of Exchange Server, so future upgrades and updates should not break this functionality.
The number of server types and roles has been reduced. Previously there were a few different types of Exchange servers that could make up a deployment, including mailbox servers (where messages lived), hub transport servers (where messages and items were routed between other Exchange servers in an organization, especially when there were multiple physical locations involved), edge servers (which caught messages coming in from other systems, including Internet mail) and unified messaging servers (which hosted voice mails, IP and Voice over IP calling plans, and other voice-related tasks).
In Exchange 2013, there are now simply mailbox servers and client access servers (CASes), and there is no longer a hub transport role or a unified messaging role as there was in Exchange Server 2010. Fewer pieces equal less complexity, a boon for administrators who had to manage multiple server types in a variety of deployments across the world. It also makes patching and regular maintenance easier, with fewer possible points of failure.
The Exchange Management Console (EMC) is gone. The EMC and its Microsoft Management Console-based operations have been replaced by a Web-based console called the Exchange Management Shell, which mimics the controls available in Office 365. Along with the revamp, some operations that previously were handled with the EMC are now possible only with PowerShell cmdlets. For example, the mail flow and performance troubleshooters are gone, as is the Exchange Best Practices Analyzer.
The Exchange Management Shell now also offers access to the improvements in PowerShell 3.0 and becomes the preferred administration environment for Exchange 2013 deployments, with many operations only possible from the command line. This is an advantage for organizations with big Exchange deployments, since you can now script and take advantage of PowerShell command-line operations to consistently administer your environment. (For smaller shops and administrators without PowerShell experience, however, it is no advantage at all.)
A powerful tool to reduce the amount of sensitive data that leaks outside of the boundaries of the organization is written directly into the new transport rules. Many organizations experience data compromise through email: Your users, either on purpose or completely inadvertently, email sensitive or otherwise privileged information outside of your company's boundaries. Not only can this cause a significant monetary loss in terms of your potential exposure to litigation, but it can also involve sanctions from regulators, payment industry organizations and other outfits.
There has been a market for third-party tools that plug in to the mail flow of a company and inspect data going out. However, that has always been an additional expense and one that comes with some complexity in terms of deployment, because it is additional code that is riding on top of an already deployed system. Now, as of 2013, data loss protection (DLP) is a feature that is built into the Exchange platform.
This allows you to set up policies that do one or more of the following: