We would like to welcome Ms. Maurene Caplan Grey,  Founder & Principal Analyst of Grey Consulting as she presents her first article to MessagingTalk.org readers.

Introduction

Microsoft Exchange Server loyalists expect new releases to deliver performance and individual productivity improvements. Their expectations will be met in Exchange 12 – although architecture redesign may be required.This paper will help you understand the major items that will impact planning decisions.

Time to Start Migration Plans

While the upgrade from Exchange Server 2000 to Exchange Server 2003 was considered a point release in complexity, the upgrade to Exchange 12 (the code name for next-generation Exchange) will be a major release.

We expect Exchange 12 to be generally available (i.e., “go live”) the first half of 2007. However, you need to start migration planning now – even if you just migrated off of Exchange 5.5. Very preliminary plans for major upgrades should start years in advance of actual deployments. Exchange 12 beta 1 was released 14 December 2005. Expect product development change as Exchange 12 moves through its beta cycles.

Fear of 5.5 Migration Déjà Vu

Veterans of the Exchange 5.5 upgrade may be skeptical about the ease of migration from Exchange 2000 or 2003 to Exchange 12. Exchange 12 will run only on 64-bit servers (x64). Similarly, the Longhorn release of Windows Small Business Server and mid-market Centro will only support 64-bit servers. (Windows Small Business Server and Centro are technology and licensing bundles, which include Exchange.)

In developing your Exchange 12 timeline, factor interdependencies with infrastructure or application software that relies upon or is required by Exchange 12. Examples may include the Real-time Communications (RTC) Server applications, Office (which includes Outlook) and third-party applications. As Exchange 12 and Office 12 are planned to be released to production at approximately the same time, determine the mix of applications and mix of versions that may need to co-exist in production. Develop several scenario deployments for testing purposes.

Lifecycle Support

Refer to Microsoft’s lifecycle support schedule when developing scenario deployments. The following table covers Exchange 2000 and 2003. It is preferable to align your timelines to the mainstream support retirement dates. Extended support can be costly.

Exchange Support Lifecycles

Products Released	General Availability Date	Mainstream Support Retired	Extended Support Retired
Exchange 2000 Conferencing Server	11/29/2000	12/31/2005	12/31/2010
Exchange 2000 Enterprise Server	11/29/2000	12/31/2005	12/31/2010
Exchange 2000 Server Standard Edition	11/29/2000	12/31/2005	12/31/2010
Exchange Server 2003 Enterprise Edition	9/28/2003	9/30/2008	9/30/2013
Exchange Server 2003 Standard Edition	9/28/2003	9/30/2008	9/30/2013

Source: Microsoft (May 2005)  

Extended support for Exchange 5.5 ended 31 December 2005. We anticipate less than one percent of the companies currently running Exchange 5.5 will still be on it when Exchange 12 is released. Exchange 5.5 servers will not be able to upgrade directly to Exchange 12, rather they will need to upgrade to an interim release first.
   
See http://support.microsoft.com/gp/lifeselect for lifecycle support across product families.

The 64-bit Frenzy

The media has attacked Microsoft on their decision to only support 64-bit servers for Exchange 12. The reality is that the majority of hardware providers are phasing out their 32-bit servers. However, this does not mean that hardware vendors have set 32-bit end-of-life dates. Expect that hardware vendors will leverage Exchange 12 to promote greater customer demand for their 64-bit servers.

The outcry over Microsoft’s 64-bit decision lies in its history of “mushrooming upgrades,” i.e., to upgrade one application requires upgrades of multiple applications and hardware.

The large majority of enterprises using Exchange 2000 or 2003 had purchased new 32 bit servers as part of its migration from Exchange 5.5. In planning a migration to Exchange 12, the enterprise must balance the depreciated value of its current 32-bit servers against the cost of new 64-bit servers. Separately, consider whether the performance improvements resulting from a 64-bit server (e.g., increased memory and cache) are a “must have” versus a “nice to have” for your company.

Role-specific Servers

The term “role-specific servers” is new to Exchange 12. However as far back as Exchange 5.0, best practices for designing an Exchange architecture have been to use  function-specific (now known as role-specific) servers.

The Evolution of the Exchange Server Architecture

Prior to Exchange 2000, a typical architecture would use different servers for the bridgehead and mailbox/public folder services. If the enterprise was a heavy user of public folders that required a high degree of replication, the public folders would be installed on its own server(s).

The redesign of Outlook Web Access (OWA) with Exchange 2000 led to greater enterprise use of OWA – and another best practice of installing OWA (and possibly POP, IMAP and MAPI client-access services) on front-end servers that proxy  connections to the back-end mailbox servers.

Particularly with large, distributed enterprises, an architecture of function-specific servers can lead to better performance. The degree of function-specific servers varies across Exchange “sites.” (Sites are somewhat analogous to groups of office locations).

Exchange 12 Gives Birth to Role-specific Servers

Exchange 12 extends the server architecture with the new Edge Services and Unified Messaging Services.
Edge Services are deployed at the outmost perimeter of the e-mail network. Edge Services manage e-mail security services (e.g., anti-virus and spam filtering) and Routing Services. In this   context, Routing Services refer to the “handoff” of e-mail messages to and from the Internet – commonly referred to as SMTP (Simple Mail Transport Protocol).

Unified Messaging Services comprise voice messaging and fax services. When used with traditional e-mail messaging, voice, fax and e-mail are delivered to a single Inbox.  For example from within the Outlook or OWA Inbox, a voice mail appears as a new e mail message with a voice mail message type (e.g., .wav). Windows Media Player is embedded within the message itself. Earlier third-party unified messaging applications displayed the voice mail as a .wav file attached to the e-mail message.

Conversely, an e-mail message could be accessed through your telephone voice mail – whereby the message would be “read” to you (using Outlook Voice Access with speech recognition and text-to-speech translation – new to Exchange 12).

A fax appears as a .gif or other graphic file attached to the e-mail message.

Edge Services and Unified Messaging Services are optional. Exchange 12 can be deployed with one of the services or neither of the services.
 
An Exchange 12 role-based architecture, with Edge Services and Unified Messaging Services, looks like this:

Exchange 12 Role-based Architecture

Source: Microsoft (January 2006)

As with prior releases of Exchange, architecture decisions will need to be made site specific, while considering the relationship of the site to the overall Exchange environment.

What You Need To Do Now

This paper only addresses publicly known major Exchange 12 considerations. We advise enterprises to exercise a high degree of due diligence before making any migration decisions.

• Develop a top-level Exchange 12 deployment timeline, understanding that it will undergo many refinements.
• Align your Exchange 12 architecture changes to minimize the impact on your Active Directory architecture. Consider applications outside of Exchange that are or will be using Active Directory.
  

Discuss/Post to digWin