First impression on unpacking the Q702 test unit was the solid feel and clean, minimalist styling.
Microsoft's marriage of easy communications
- — 19 October, 2007 11:08
Exchange Server 2007
Since our test of the Exchange 2007 beta last August, we've encountered the new e-mail platform in the course of several other tests, sometimes with mixed results. During this period, Exchange went from beta 2 all the way to shipping code and now has a service pack pecking its way to final release.
One key point from the beta preview bears repeating: Exchange 2007 is a big change from Exchange 2003. Deploying Exchange 2007 will make your mail server management life easier in the long run, but it will have short-term impacts on your physical server budget, the number of servers in your racks, your day-to-day management tools, and even the way your users access their messaging and scheduling data. You'll have better security, better redundancy, easier management overall, but even experienced Exchange administrators will have to learn new ways of doing things. Furthermore, if you buy into several critical new capabilities, you will probably need to run more instances of the server to support the same number of users, and that means more points of potential failure. For example, Exchange 2007 gives Windows Mobile smartphones full network citizenship, with their own mail accounts, which can add a whole new dimension of desktop management headaches if you're not careful.
Exchange 2007's new hardware requirements aren't limited to the 64-bit-only support. Industry feathers were ruffled when Microsoft announced that Exchange was going 64-bit only (and that it wasn't going to be the only server in Redmond's family to go that route), but after a year of reflection, we think the 64-bit move was a solid choice on Microsoft's part. First, most servers sold during the past two years are already 64-bit capable and that trend is only going to increase. Second, moving to a 64-bit CPU means that more RAM can be used to cache the message database and that means faster performance and less strain on the server's disk system. It's the future, deal with it.
What will be a hardware consideration as well as your most important initial planning criteria is Exchange 2007's updated server roles. Microsoft has expanded the number of Exchange server roles available to five, and that will most likely expand the number of physical Exchange servers you'll be running. Your meat is the Mailbox server role, but a close second in importance is the CAS (Client Access Server), which manages all the proxied client connections, including Outlook Web Access, something you most certainly want.
There are also two transport roles, one internal and one external. On the outside, it's the Edge Transport server, which is not so much a router as a DMZ-safe filtering instance. A good move, but SMBs might do better to forego the DMZ-based filtering strategy and instead look to an externally hosted solution such as Microsoft's own Forefront line or something from a competitor such as MessageLabs. Internally, your transport role is the Hub Transport server, basically an e-mail router for large, distributed enterprise deployments. Sub-1,000 user installations need not apply.
The last server role is that of Unified Messaging. This one routes all the required data between CAS and Mailbox roles and external communications platforms including IP PBX systems and, yes, Office Communications Server 2007. Microsoft has made the actual user configuration of OCS/Exchange surprisingly straightforward, but you'll need a Unified Messaging server running and it needs to be updated with Windows Server 2003 SP1.
Postdeployment, administrators will be working with the new face of Exchange management, Exchange 2007's ESM (Exchange System Manager). ESM's tree-style view is quite different from the 2003 manager. Once you get the hang of it, ESM is more efficient than the previous generation, but getting the hang of it is not a trivial exercise. ESM is also different under the hood. This version has been built entirely on the Exchange Management Shell, which is an extension of the Windows PowerShell scripting environment. The upside is that folks willing to dig into EMS will be able to write their own scripts to automate tasks. The downside is that Microsoft has made every facet of Exchange management functional within the command-line EMS environment, but not quite every facet functions within ESM. Parts of Exchange Server 2007 SP1 are supposed to address this inequality and make both views equal in terms of management muscle (here again, see Exchange Server 2007 Service Pack 1 packs plenty).