Motivations for the Exchange Server 2007 transport redesign


After the success of Microsoft Exchange Server 2003, the Microsoft Exchange team was pondering what the next-generation Exchange Server should look like. We had several high-level goals, which we won't go into in this blog, but let's look at a few specific details that motivated us to redesign for Exchange 2007:

  • Separation of server roles
    • Customers liked the idea of Exchange playing different server roles. For example, it was easier for administrators to maintain a Mailbox server role and a Transport server role separately. The separation was good for introducing new scenarios such as Unified Messaging and for building robust components.
  • We wanted to create the first ever Microsoft Edge Transport server
    • Microsoft Exchange decided to introduce a new stand-alone server role in the perimeter network and to fulfill our customers' needs in that area. To achieve this, we had to design a unique gateway management model that isolates servers (active directory) in the perimeter network from the rest of the organization. It made sense to redesign instead of change Exchange 2003 behavior to achieve this goal.
  • Efficient routing
    • For some time, we'd been thinking about how to change the underlying routing concept so that it's easy for customers to deploy Microsoft Exchange. The decision was made to move to an Active Directory-based routing concept instead of a unique Exchange routing group concept. Also, we wanted to figure out how to remove the link state concept to achieve robust server-to-server mail delivery. Redesigning helped give our architects the freedom to explore this area.
  • A better extensibility model
    • With our customers' ever-growing need to extend the Microsoft Exchange platform, it was apparent that we needed to provide an agile and rock-solid extensibility layer. Redesign would empower agent developers
  • Extraction from the Microsoft Windows code base
    • We didn't want our customers to have any protocol prerequisites, such as Internet Information Services (IIS), to installing Microsoft Exchange, and we knew that maintaining two SMTP code bases was expensive for us. The redesign helped Microsoft Exchange eliminate the IIS dependency from the SMTP architecture.
  • In-house benefits
    • This redesign helped us achieve a much cleaner infrastructure to support new initiatives like the Trustworthy Messaging and Messaging Policy.
  • Managed code for better security
    • As we made the redesign, the Microsoft Exchange team decided to take an additional step to use managed code. This provides better security against buffer overflow type issues and also enhances Microsoft Exchange developers' long-term productivity.

- Agnita Pandian

Comments (3)
  1. Oren Sreebny says:

    How about separating calendaring from email? That seems like the basic architectural flaw with Exchange to date.

  2. RDC1 says:

    unless you are a pure E2007, the customer will still have to think alot about Link state, certainly if their currnet routing topolgy is complex!

Comments are closed.

Skip to main content