Introduction
During the early stages of the development phase of Exchange Server 2007, rumors about changing the store to SQL circulated the Internet. But these plans were dropped relatively quickly and chances are we won’t see an Exchange product where the store is based on SQL before E15 (yes that’s the version after E14!). But this doesn’t mean that Exchange Server 2007 doesn’t introduce any store related changes and improvements, because although the Exchange still is based on a more or less unchanged ESE database a lot of work went into providing a much more scalable, reliable, and optimized product which performs better than was the case with previous versions of Exchange.
Exchange 2007 – A True 64-bit Application
It shouldn’t come as a surprise for any of you that only the 64-bit version of Exchange 2007 will be supported in production environments. Because Exchange 2007 is real native 64-bit application, it can access much more memory which ensures high performance and reliability as mailbox sizes and the number of user accounts per server increase. The default mailbox as well as Public Folder size in Exchange 2007 is nothing less than 2GB!
Figure 1: New Default Mailbox Limits in Exchange 2007
Because it’s a 64-bit application, Exchange 2007 reduces input/output (I/O) requirements up to 75 percent in I/O per second. Exchange Server 2007 also makes better use of existing storage systems and will allow Exchange administrators to use low-cost options like Direct Attached Storage (DAS) in even the most demanding environments.
As you can see in Figure 1 the Deleted items and mailbox retention settings also have changed. In Exchange 2003 the default deleted items retention setting was 7 days, but this is 14 days in Exchange 2007. This is also true for Public Folders.
Exchange 2007 Storage Groups and Databases
A Storage Group is a grouping of Mailbox and/or Public Folder Databases, which shares a single backup schedule and a single set of Transaction log files. Storage Groups are managed using their separate server process and the idea behind splitting databases up in Storage Groups is primarily to reduce the overhead that results from multiple sets of transaction log files.
As most of you recall, Exchange Server 2003 Standard edition supported 1 Storage Group and 2 Stores – one Mailbox and one Public Folder Store (when excluding the Recovery Storage Group of course). Exchange Server 2003 Enterprise Edition supported a total of 4 Storage Groups each containing a maximum of 5 store databases. The limit of a database in Exchange Server 2003 Standard edition was 16 GB (although raised to 75 GB when Exchange 2003 Service Pack 2 was applied). There was no limit on a database when talking about Exchange Server 2003 Enterprise edition (well actually there is a 16 Terabyte limit but this limit is caused by hardware).
Exchange Server 2007 comes in two flavors, a standard edition and an enterprise edition, just like previous versions of Exchange. The Mailbox Server when talking about the Exchange Server 2007 Standard edition supports a total of 5 Storage Groups and 5 databases. Unlike Exchange 2003 and previous versions of Exchange there’s no longer a database storage limit in the standard edition. The Mailbox server in the Exchange 2007 Enterprise edition supports up to 50 Storage groups and a maximum of 50 databases per server. Exchange 2007 allows you to create up to 5 databases in each Storage Group as is the case with Exchange 2003, but best practice is to create 1 database per Storage Group. So why should you have a one to one relationship between storage groups and databases? Well primarily because you’ll be up and running a lot faster considering disaster recovery scenarios, etc.
Figure 2: Database Management in Exchange Management Console
Like is the case with Exchange 2003 it’s still ok to keep all Storage Groups on the same spindles, but in terms of performance it’s better to keep them separated, although this would be quite unrealistic for most organizations that were using, for example, 30 Storage Groups!
As I already mentioned databases in Exchange Server 2007 are still based on a more or less unchanged Extensible Storage Engine (ESE). As most of you are aware, ESE relied on two databases files, an .EDB and a .STM file. The purpose of the streaming file (.STM) was to house raw Internet content message streams as defined in Request for Comments (RFC 822). Since the .EDB file isn’t very suitable for storing raw Internet content message streams, the idea of introducing the .STM file was understandable, but with Exchange Server 2007 the .STM file has been removed together with the Exchange Installable File System (ExIFS). The reason behind this decision was in order to reduce the overall I/O footprint for Exchange Server 2007.
However, unlike previous versions of Exchange, Exchange Server 2007 no longer maintains single-instance storage of message bodies, only for attachments. There is one exception to this rule and that is when a set of mailboxes has been moved from an Exchange 2000 or 2003 Mailbox store to an Exchange 2007 Mailbox database during a transition. In this situation Exchange 2007 maintains single-instance storage for both attachments as well as message bodies. For additional details see this blog post on the MS Exchange Team blog.
Transaction Log File Size Changes
Another change in Exchange Server 2007 is that the transaction log files are now 1MB instead of 5MB as was the case in previous versions of Exchange.
Figure 3: New Transaction Log File Size in Exchange 2007
So what’s the reason behind this decision? Well in previous versions of Exchange if a crash destroyed the last few log files that hadn’t been committed to the database yet, you would need to restore or repair the database to have it mounted again. Exchange Server 2007 introduces a new feature called Lost Log Resilience (or LLR in short) which will hold the last few log files in memory until the database is shut down. This means that you will never have a case where part of for example log file 5 has been written to the database, but part of log file 4 hasn’t. The benefit of this is that if you don’t have anything against losing the last few log files, you can tell Exchange to simply throw away the data and mount the database.
So the reason why the log files has been reduced to 1MB is to reduce LLR exposure. Now if you lose the last log, it costs up to 1MB of the most recent data instead of 5MB.
Another improvement worth mentioning is that the log file sequence numbers now can go above 1 million. As some of you might be aware previous versions of Exchange had a limit of 1 million, so if a database had been running long enough to generate a million logs, you had to shut it down and start over from log #1 (“reset the log sequence”). This would happen every few years for most databases. With the smaller log sizes and the increasing amount of messages passing through most databases, the Exchange Product group decided 2 billion log files (per storage group!) would be a better maximum log number.<?
Public Folders
Public Folders are still supported in Exchange server 2007, but bear in mind they have been de-emphasized which means that there’s a good chance they won’t be included in the next version of Exchange (currently codenamed E14). With this in mind it’s a good idea to start thinking about migrating to another solution such as SharePoint.
Note:
Even though Public folders have been de-emphasized in Exchange Server 2007, Microsoft will support them until the end of 2016, so you have got plenty of time.
One major drawback is that the Public Folder related administration tasks you can do from within the Exchange Management Console are extremely limited. So if you need to do tasks other than create, delete and move Public Folder databases as well as configure limits, etc. you will, depending on the specific task, need to do so using either the Exchange Management Shell, an Outlook client or System Manager on an Exchange 2003 Server still part of the Exchange organization.
Figure 4: Creating a Public Folder using the Exchange Management Shell
So if your organization makes heavy use of Public Folders, I recommend you keep an Exchange 2003 Server running in your organization, until you have migrated away from the Public Folder hierarchy or until Exchange 2007 SP1 is released (which hopefully includes administration tasks in the EMC GUI!).
High Availability with Exchange 2007
As you probably have seen in some of my recent Exchange 2007 articles, Exchange 2007 also includes several new high availability features such as Local Continuous Replication (LCR), Cluster Continuous Replication (CCR) and Single Copy Clusters (SCC). I won’t dig into those here but instead refer you to the respective articles:
-
-
Installing, Configuring and Testing an Exchange 2007 Cluster Continuous Replication (CCR) Based Mailbox Server (3 part article series)
Note that LCR are supported with Exchange 2007 Standard edition, but that you need the Exchange 2007 Enterprise edition in order to take advantage of the CCR and SCC features. Since both CCR and SCC are based on the Microsoft Clustering Service (MSCS), you also need to make sure you install Exchange 2007 on a server with Windows 2003 Server Enterprise edition if you want to use these features in your environment.
That was all for this time, you should now be even better prepared for the planning phase of Exchange 2007 deployment in your organization.
