 | |||
|
|
||
| |||
| |||
| |
|
Home > Part 3: The Exchange 2007 Mailbox Server role |
| |
|
|
|
|
| Tutorial: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
|||||||||||||||||||||||||||||
If you've been working with Exchange Server for any length of time, the purpose of the Exchange 2007 Mailbox Server role should be obvious. Mailboxes sit at the core of what Exchange Server does, and the Mailbox Server role is dedicated to hosting mailboxes and/or public folders for your end users. Needless to say, hosting all that storage is a critical part of your Exchange Server subsystem. While many of you have probably segregated your Exchange 2000 and Exchange 2003 environments into mailbox servers, public folder servers and bridgeheads, you shouldn't assume feature parity between, say, an Exchange 2003 mailbox server and the Mailbox Server role in Exchange 2007 -- there are many changes. For starters, Exchange Server 2007 now supports up to 50 stores and 50 storage groups. This may come as a surprise, given the history of memory fragmentation issues that some of you may recall from the Exchange 2000 and Exchange 2003 beta days. However, keep in mind that Exchange 2007 is now 64-bit only. While Microsoft will be providing a 32-bit version of Exchange 2007 for evaluation purposes, Microsoft will not support anything but 64-bit in your production environments. If you know a thing or two about memory architecture, you'll quickly realize that making this move has provided Microsoft with far more resources than were ever available in the "old days", and memory fragmentation is no longer an issue. Those of you deploying Exchange Server with multiple mailbox stores per server for faster recovery will want to consider using separate storage groups for each store. Having a one-to-one relationship between databases and transaction log file sets will, of course, drastically simplify recovery should transaction log file replay ever be required. The 64-bit architecture also enables Exchange Server 2007 to handle much larger mailboxes than previously. Practically speaking, you should be fine scaling to 3,000 or 4,000 mailboxes on a well-architected system. MAPI- and RPC-based clients (such as Microsoft Outlook 2003, for example) continue to connect directly to the Mailbox Server. Another obvious change in Exchange Server 2007 is the absence of the streaming media file (STM) as part of the Exchange databases. As Microsoft looked closely at how the Exchange 2003 database was functioning "in the wild," they found that STMs were not used as much as they expected; and at the end of the day, it was probably much simpler to move back to a single database file as part of the database architecture. Some other changes from a database standpoint are the addition of Local Continuous Replication (LCR) (i.e., enabling a second copy of a store for disaster recovery purposes) and Clustered Continuous Replication (CCR) which provides support for stretch clusters. Public folders are also now optional. So, in theory, you could run a pure Exchange 2007 environment without any public stores. This means that all system public folder functions that we've grown accustomed to over the years are now either gone or moved to another area of Exchange Server. For example, the electronic forms libraries of years gone by are now completely gone, with Microsoft InfoPath as the recommended replacement. The schedule+ free/busy folder is now gone too, replaced by the Calendar Assistant. The Mailbox Server role enables all of the usual database and storage group management tasks you'd expect. Another fundamental change that has happened with Exchange 2007 is that the management console has been completely rewritten. In Exchange 2007, Exchange System Manager (ESM) is now called the Exchange Management Console (EMC) and is based on a much larger command-line set of functionality in the Exchange Management Shell (EMC), which in essence allows you to do everything you've ever wanted to do to administer your Exchange server (and more) from simple command line "cmdlets" (pronounced 'command-lets'). This command-line interface is pervasive across all Exchange 2007 server roles and provides many new opportunities (and challenges!) for managing your Exchange server. For example, if I wanted to create a new database in a new storage group, I could invoke EMC and type the following commands: New-StorageGroup AslanStorageGroup –Server NARNIAEXMBX01 New-MailboxDatabase –Name "ExecutiveManagement" –StorageGroup "AslanStorageGroup" This would create a new storage group for "Aslan" with a database for "Narnia" executives to use. The Mailbox Server role also handles resource scheduling (note that there is now a new differentiation between "user mailboxes" and "resource mailboxes"), including meeting rooms management, equipment management and resource scheduling. There is also a new Calendar Attendant to handle meeting requests, updates, forwarded meeting requests, and those pesky out-of-date meeting requests in a much more seamless manner than ever before, and with no end user interaction required. Out-of-Office (OOF) functionality has been dramatically enhanced and includes:
One final point worth of note: If you plan to deploy your Mailbox servers in a clustered configuration (either active or passive), you cannot co-locate any other roles with the Mailbox Server role.
|
|
|
|
|||||||||||||||||||||||||||
Home: 
David Sengupta, Microsoft Exchange MVP
|
|
 |  |  | |  | |  | |  | |  | |  | |  | |  | |
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
