Over the past ten years, Microsoft has released five major versions of Exchange Server: Exchange Server 4.0, Exchange Server 5.0, Exchange Server 5.5, Exchange 2000 Server, and Exchange Server 2003. Each release has strengths and weaknesses, and with each release we've enjoyed some major new functionality. Unfortunately, we've also often had to tweak the software or change the way we work or the way our network infrastructure is set up to accommodate a new release. Although Exchange Server 2007, formerly known as Exchange 12, isn't a departure in that regard, it incorporates functionality that administrators and users will be excited about. Let's look at some of the major new features in Exchange 2007, and I'll discuss the likely changes that administrators face with this version of Exchange.
Exchange 2007 Design Goals
Microsoft begins planning for an Exchange release well in advance—planning for Exchange 2007 began before Exchange Server 2003 even shipped. The point behind this advance-planning process is to let Exchange designers and developers identify trends in the computing world and figure out the best way to meet them; the hoped-for result is that the final product is relevant by the time it ships. This process has worked pretty well for Microsoft in the past. For Exchange 2007, Microsoft isolated three primary goals.
More control for IT administrators. Administrators have long complained about some aspects of Exchange 2000 and 2003, including the relative difficulty of helping nontechnical end users set up their Outlook profile and the complexity (some would say "richness") of the Exchange System Manager (ESM) tool. In addition, several different programming interfaces exist for writing scripts and tools that manipulate Exchange data, yet there are still some things you can do only through the ESM interface.
More Inbox value for end users. This phrase seems meaningless until you consider what "Inbox value" users actually get from their message, calendar, and contact data. Microsoft's vision for Exchange 2007 is to make all the data from the Inbox ubiquitously available from the desktop (through Outlook), the Web (through a revamped version of Outlook Web Access—OWA), mobile and wireless devices, and even telephones. There are also major improvements in the way Exchange 2007 handles meeting and resource booking—features that users will immediately welcome no matter what client they're using.
Active messaging protection. This is a fancy way of saying that Exchange 2007 is intended to do a better job of blocking viruses, filtering spam, and protecting mail content from tampering or interception along the delivery route.
These three categories are broad. Let's break down Exchange 2007's major new features according to feature area.
Architecture and Roles
Both Exchange 2000 and Exchange 2003 maintain two server roles: front-end servers handle client connections, and back-end servers contain mailboxes. In Exchange 2007, the concept of role separation has been extended to cover five server roles. One server can handle multiple roles simultaneously, and you can dynamically add or remove roles on an existing server without reinstalling Exchange. The five roles are:
- Client Access Server (CAS). Proxies client connections, much like an Exchange 2003 front-end server would do. The CAS also provides OWA service.
- Mailbox server. Holds mailboxes by default but can accept MAPI connections. You can combine the mailbox and CAS roles.
- Edge Transport server. Performs message hygiene and filtering tasks. Edge Transport servers don't have to be part of an Active Directory (AD) forest and can safely be placed inside the network demilitarized zone (DMZ).
- Hub Transport server. Routes mail between mailbox servers inside the organization.
- Unified Messaging server. Routes communications between PBX or telephone systems, CASs, and mailbox servers.
If you want an Exchange 2003?style organization, you can use mailbox servers in place of your back-end servers, and CASs in place of the front-end servers. To better match your environment, you can design an architecture that separates the new roles by placing each on its own machine.
64-Bit Support and Scalability
In November 2005, Microsoft dropped a bomb with its announcement that Exchange 2007 would run only on 64-bit (i.e., x64) hardware. The announcement immediately generated discussion in various online communities, most of which centered on whether the change was a good move for Microsoft or not. A careful analysis shows that the 64-bit restriction is a sensible move on Microsoft's part. The vast majority of servers sold today are already 64-bit-capable; both AMD and Intel have been shipping server CPUs that support 64-bit address spaces for more than 18 months, and because these components cost the same as 32-bit components, they have been quickly adopted by major server manufacturers. This means that if you possess hardware purchased since January 2005, the odds are excellent that it's already 64-bit. If you're still on 32-bit hardware, you can align your hardware refresh cycle with your Exchange 2007 deployment; alternatively, you can buy new hardware when it's convenient and deploy Exchange 2007 on this hardware when the software ships.
Why did Microsoft make this decision? For several reasons, the most important of which involve scalability and performance. The two bottlenecks that limit the number of users you can host on an Exchange machine are typically the disk subsystem (on which you need lots of I/O operations per second—IOPS—to provide good performance for large numbers of users) and the amount of address space reserved for use by the kernel. Moving to a 64-bit addressing model means that you can put a huge amount of RAM into a server that Exchange can productively use to cache database pages. With large RAM installations, the number of disk requests Exchange has to make drops by as much as 70 percent, eliminating the storage system as a bottleneck. A bonus is that adding large amounts of RAM is typically cheaper than adding multiple physical disks. In addition, 64-bit addressing fixes the kernel resource problem by greatly increasing the address space available to the kernel.
Prev. page
[1]
2
next page 
