CloudServus - Microsoft Consulting Blog

An early look at Exchange 2013 - Microsoft Consulting Services - CloudServus - United States

Written by cloudservuscom | Oct 2, 2012 3:21:57 PM

This past week at the Microsoft Exchange Conference 2012 in Orlando, Microsoft Exchange Product Team, MVPs, MCMs, and community members gathered to discuss the impending release of Exchange 2013.  I say “discuss” because that’s how the conference was structured.  This wasn’t your typical death-by-PowerPoint with a few demos in between.  These were fully interactive sessions.  The first day laid the foundation for the conference by giving us an overview of the new Exchange 2013 and it’s cloud version.  The following days were really deep-dive discussions with product team members, and other experts with early knowledge of the product, on topics generated by the attendees.  Here is what I gathered from those sessions.

Exchange 2013 Overview

The first thing to know about the new Exchange is that it is a complete rewrite from previous versions.  Of course there are chunks of code that operate similar to the way they used to, but from an architect/administrators perspective things have changed significantly.  Microsoft has gained a lot of knowledge from the deployment and operation of Office 365.  They used that knowledge to rewrite Exchange 2013 to operate on-premise, in the cloud, or a hybrid.

Exchange 2013 Server Roles – “These are not the roles you are looking for”

  • Mailbox Server – The mailbox server role now performs all of the processing for a particular mailbox.  It includes all of the components in Exchange 2010: Client Access protocols, Hub Transport services, Mailbox databases, and Unified Messaging.  Wait… wha??? Yes, the mailbox server does all rendering of data for a given mailbox.  It also owns all of the Transport services for routing traffic.
  • Client Access Server – The Client Access Server roles still exists in the new Exchange, but in name only.  Same name, new role.  The Exchange Product team often referred to this role as CAFÉ… Client Access Front End.  The CAS now provides authentication, redirection, and proxy services from the client to the mailbox servers.  It will proxy of all the Client Access services: HTTP(S), Outlook Anywhere (RPC over HTTP), IMAP, POP, SMTP, and Unified Messaging call routing.  Notice anything missing?  That’s right MAPI/RPC no longer exists in the new Exchange.  This removes the requirement for another namespace to manage (Remember CAS Array vs Outlook Anywhere?) and the RPC client access service no longer needed on the CAS. The CAS server is a stateless server, meaning that no data is stored on the server and the heavy lifting is done on the backend.  The roles are loosely coupled.  Strange… it’s sounding more and more like Exchange 2003… but much improved of course.  In 2007 and 2010, the tight coupling of the roles had several downsides including version dependency, geo-affinity (requiring all roles in a specific site), session affinity (requiring expensive layer 7 hardware load balancing), and namespace complexity.  I’ll try to explain more in another blog post on High-Availability, but the moral of the story is clients connect through CAS, but CAS just proxies the connection to the mailbox server where your database is active, including in another AD site.

Ok, so the hub role is combined with Mailbox and UM is split between CAS and Mailbox… You might be asking, “Where is Edge?”  Edge is not available in Exchange 2013.  If you are utilizing Exchange 2010 Edge servers, they can still be used with 2013 and EdgeSync can be set up between Mailbox role and your 2010 Edge servers.  The new Exchange also has some basic antimalware built-in.  I don’t know if I ever heard it stated, but my guess is that Edge was not widely used in the Exchange world.  Most organizations that I’ve worked with utilize some type of antivirus/antispam appliance or a hosted service, so rather than support this role and continue to maintain and troubleshoot your Edge server, Microsoft prefers you to use Exchange Online Protection (the service formerly know as Forefront Online Protection for Exchange).  If you haven’t caught it yet, the Forefront brand is being discontinued.

New Features in Exchange 2013:

This not pretend to be an all inclusive list of new features, but some of the highlights that I’ve seen.

  1. Exchange Admin Center: The management of your Exchange 2013 environment can now be performed through the Exchange Administration Center.  This web-based console replace Exchange Management Console and Exchange Control Panel.  All management is still based on PowerShell, so the Exchange Management Shell is still available.  The Exchange Admin Center is similar to what you saw in ECP, but it’s more extensible to support on-premise, hybrid, or online.  This console is also web-based, so it’s accessible across multiple platforms.  This could be very handy for example, if you’re on the road and only have your mobile devices available. 
  2. Public Folders:  This is not exactly a new feature, but Public Folders are now specially designed mailboxes that store both data and hierarchy information.  Exchange 2013 does not support Public Folders in their current form (i.e. Public Folder databases and replication).  Instead, Public Folders will need to be migrated to a mailbox and then linked to form a structure similar to your old Public Folder structure.  This is nice because you no longer have to manage a PF database or troubleshoot why it is not replicating.  The mailboxes will leverage existing high-availability through your DAG structure and replicated to each DAG member for HA and DR.  This means Public Folders move from a multi-master to a single-master replication model. I suspect that the migration process is not clean and will be time consuming.  Nonetheless, it’s good to see some progress made.
  3. Managed Availability: Microsoft has learned from their cloud deployment that Exchange needs not only monitoring of it’s services, but also automated actions to recover from outages at the server or service level.  Managed Availability is a process by which Exchange monitors it’s services and takes actions to restart services, etc.
  4. Security in the new Exchange (I’ll talk more about these in another post or read about them from MS)
      • In-Place Discovery, Hold, and Retention: There are some big improvements in this area.  Lync 2013 can now utilize Exchange to archive messages, then utilize your Exchange retention policies to enforce policy.  There is also the ability to leverage SharePoint eDiscovery Center to discover documents, fileshares, email, Lync content, etc.  
      • Data Loss Prevention:  Exchange now has built in DLP abilities through transport rules.  You can scan for patterns, such as credit card numbers, Social Security Numbers, etc. and then take action on items that you’ve found.  This could help your organization protect your data, as well as limit their exposure to lawsuits due to exposure of vital information.
      • Azure Active Directory RMS and Encrypted Email: This is really more of an Office 365 feature, but I thought I’d list it here as well.  It might provide some benefits in a Hybrid environment.  I still need to do some testing and research on this.
  5. Hybrid Migration Wizard:  We got a demo of the Hybrid Migration wizard for Office 365 at MEC.  It is significantly improved over even Exchange 2010 SP2. 
  6. Certificate Monitoring:  This one is BIG!!!  How many of you have had your environment go down for some unknown reason, only to figure out that a certificate had expired.  Well Exchange 2013 Managed Availability includes the ability to monitor your certificates for expiration.  Thirty (30) days prior to expiration a notification will appear in the Exchange Admin Center.  This gives you time the update it before your current monitoring system (i.e. your users) notify you that “something is broken”.

 

Migration Scenarios:

Most of us are already running a version of Exchange on-premise, so you’re probably wondering how you are going to approach upgrading to Exchange 2013.  The only supported upgrade paths are from Exchange 2007 or 2010 to the new Exchange.  This is pretty typical of a Microsoft upgrade to support N–2 releases.  Here is a general guideline, but Microsoft will be updating the Microsoft Exchange Server Deployment Assistant as we get closer to release.  Here is the catch.  Although Exchange 2013 will be released sometime in Q4, the service packs and rollup updates for Exchange 2007 and 2010 will not be released until Q1 of 2013.  In a rush to get 2013 out the door earlier, Microsoft decided to go ahead and release it, but still postpone the updates to older versions for coexistence.  Why would they do this?  Well I suspect it is to allow people to get hands-on experience with the new product and possibly to allow them to release the latest version in Office 365 sooner.  However, the Office 365 early release would still not allow a Hybrid scenario until the SPs and RUs are out. 

Note:

  • Upgrading from Exchange 2010 to 2013 DOES NOT require a legacy namespace
  • Upgrading from Exchange 2007 to 2013 DOES require a legacy namespace

Updating from Exchange 2010:

  1. Prepare your Environment
    • Verify your prerequisites
    • Install Exchange 2010 SP3 across your organization
    • Prepare Active Directory with the Exchange 2013 schema
    • Validate existing client access
  2. Deploy Exchange 2013 servers
    • Install both Exchange 2013 CAS and Mailbox
  3. Obtain and Deploy Certificates
    • Obtain and deploy certificates on your E2013 CAS servers
  4. Switch Primary Namespace to Exchange 2013 CAS
    • Exchange 2013 fields all traffic, including traffic from Exchange 2010 users
    • Validate client access
  5. Move Mailboxes
    • Build out your Exchange 2013 Database Availability Groups (DAGs)
    • Move Exchange 2010 mailboxes to Exchange 2013
  6. Repeat for additional sites

Updating from Exchange 2007:

  1. Prepare your Environment
    • Verify your prerequisites
    • Install Exchange 2007 SP3 + RU across your organization
    • Prepare Active Directory with the Exchange 2013 schema
    • Validate existing client access
  2. Deploy Exchange 2013 servers
    • Install both Exchange 2013 CAS and Mailbox
  3. Create Legacy namespace
    1. Create DNS record to point to legacy Exchange 2007 CAS
  4. Obtain and Deploy Certificates
    • Obtain and deploy certificates on your E2013 CAS servers
    • Deploy certificates on Exchange 2007 CAS
  5. Switch Primary Namespace to Exchange 2013 CAS
    • Exchange 2013 fields all traffic, including traffic from Exchange 2007 users
    • Validate client access
  6. Move Mailboxes
    • Build out your Exchange 2013 Database Availability Groups (DAGs)
    • Move Exchange 2007 mailboxes to Exchange 2013
  7. Repeat for additional sites

As you can see the process to upgrade is generally the same, except for the legacy namespace requirement in Exchange 2007.  That’s a quick overview of some of the things learned at MEC.  I’ll be discussing more in-depth as I have time.