Designing Storage for Exchange 2007 SP1

Paperback (Print)
Buy New
Buy New from
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 96%)
Other sellers (Paperback)
  • All (5) from $1.99   
  • New (3) from $54.55   
  • Used (2) from $1.99   
Sort by
Showing 11 – 10 of 0
We’re having technical difficulties. Please try again shortly.
Showing 11 – 10 of 0
Sort by


This book will help you understand the new choices and possibilities available in designing your storage environment for Microsoft Exchange Server 2007 SP1. The move of Microsoft Exchange Server from a 32-bit application to the 64-bit world reduced the I/O footprint on the storage subsystem. This allows users to consider shared storage deployments or go the opposite way and focus on direct attached storage. Supporting large mailboxes is now possible, but how do you back up and recover the increased amount of data? Exchange Server 2007 Continuous Replication and new features in Windows Server 2008 Failover Clustering provides interesting possibilities for geographically dispersed deployments. This book explains these new built-in features of Exchange Server 2007 and compares them with application independent data replication solutions provided by high-end storage subsystems. It is critical to understand these key technologies to make the right decision which storage solution best fits your business needs. The authors share their experience from large scale deployments and depict configurations used during their projects.

•Includes a description of how the move to a 64-bit application reduced the I/O behavior
•Storage hardware technologies and Windows storage stack features for Exchange servers
•Exchange Server 2007 Continuous Replication and Windows Server 2008 Failover Clustering
•Performance monitoring and analysis to optimize the Exchange Server 2007 configuration

Read More Show Less

Product Details

Meet the Author

Pierre Bijaoui is a Solution Architect for HP Services, based in Sophia Antipolis, France. He is often involved with large customer deployments, dealing with data center and storage architectures and technologies and Windows performance tuning and optimization. Pierre has been a tutor of the unanimously acclaimed Exchange Academy program at HP since its inception and was specialized in mobility, server and storage design and performance aspects of Microsoft Exchange. Pierre is a Microsoft Certified Architect (Infrastructure). In December 2001, he published a book, Scaling Microsoft Exchange 2000: Create and Optimize High-Performance Exchange Messaging Systems, (Digital Press), updated in November 2006 for Exchange 2003 SP2.

Juergen Hasslauer is a Solution Architect for HP Consulting and Integration based in Germany. He supports customers to help them define the architecture of their IT solutions. His current focus is designing highly available Microsoft Exchange environments and infrastructure optimization using virtualization solutions. Juergen is a frequent speaker at industry conferences such as Microsoft Exchange Connections.

Read More Show Less

Read an Excerpt

Designing Storage for Exchange 2007 SP1

By Pierre Bijaoui Juergen Hasslauer

Digital Press

Copyright © 2008 Elsevier, Inc.
All right reserved.

ISBN: 978-0-08-056003-8

Chapter One

Introduction to Exchange 2007 Storage

In this chapter, we review aspects of storage design for Exchange 2007 that you should be aware of. This "launch pad" provides background information on the purpose of this book.

Where to Start?

Deploying Exchange 2007 will require you to make decisions about the type of storage you will need to provide to one of the most critical business application on the market. Microsoft Exchange is a dominant mail and messaging platform, often used also as a corporate address book and time management application.

If you think about it, email is about sending and receiving data; for users, it's having a repository of relatively unstructured data and querying that repository similar to a database. Storage is therefore a critical component in your deployment. In fact, given the tremendous progress made in the world of processors, and the adoption of 64-bit computing by Exchange 2007, storage is the most critical component in your design. This is the thing to get right from the beginning, or you run the risk of continuous problems in your deployment, eventually delivering an email service that does not help your users or customers.

When dealing with Exchange storage, we always find it necessary to first work the requirements for the storage and then figure out the best solution. Those requirements can be quite simple (e.g., I want a 5-GB mailbox) or more complex (e.g., ability to recover all Tier-1 users within 4 hours after a major disaster).

The logical flow of handling your requirements could be similar to Figure 1-1 (nonexhaustive sample).

The flow in Figure 1-1 is based on standard architecture methodology and does not pretend to be the only approach to handling requirements. In fact, many customers of Exchange 2007 already have such methodology. The need for such a structured approach is there to ensure that you provide the best solution to your problems, and not attempt to replicate a solution that, after all, does not address your problems, but others' problems. For example, are you certain that you wish to create an ISP-type mail environment with large mailboxes and no service level? Or perhaps you will want a combination of both? Or, you may want to have 1-GB mailboxes with absolutely no loss of data and to be able to sustain a natural disaster within a 100-mile/kilometer radius.

What's new with Exchange 2007?

Microsoft with Exchange 2007 has embarked on a journey that started with the 64-bit route. 64-bit computing has been possible since Windows NT4 (with Digital's Alpha processor). However, Microsoft focused their development of subsequent versions of Microsoft Exchange for the i386 instruction set (processors manufactured primarily by Intel and AMD), running on 32-bit address space. It really was not a problem until the data sets (the database hosting the mailboxes) used by Microsoft Exchange grew to a point where it was necessary to break the single private Information Store model to allow for easier manageability. With Exchange 2000, we saw the adoption of a multiple database model, where mailboxes could be held in several smaller databases, instead of just one big database in a single file. This was further extended with Exchange 2007 (up to 50 databases can be defined for a single server), now that the barriers of the Virtual Address space (3GB and a few bytes) of the Information Store process are broken, thanks to 64-bit computing. Many more databases can be handled by a single Exchange 2007 server, allowing for a better granularity when dealing with individual databases and transaction log files. The databases can be smaller in size, or even better, you can have the same number of users per server, but with a much larger mailbox size, while keeping a reasonable size for the individual databases (200GB is considered the practical maximum).

You may wonder why we discuss 64-bit computing in a book about storage. In fact, much of the storage optimization and improvements found with Exchange 2007 are due to the ability to use larger quantities of RAM (up to 10 times more RAM should be used for a high-end server compared to Exchange 2003, allowing for effective database page caching). While we discuss those new functions later in this book, you will have to remember that choosing the right memory sizing for your server is extremely important to relieve the Microsoft Exchange–induced I/O pressure on the storage subsystem components. Reducing that pressure will result in better user experience, better behavior in shared storage environments (by decreasing the burst of I/O requests and making Exchange less dependent on high-performance storage), and the ability to have more choices for your storage components.

Public folders still exist in Exchange 2007, yet Microsoft definitely put the emphasis on Microsoft Office SharePoint Server for collaboration and shared information. It means basically that if you currently run a Microsoft Exchange environment, and you use public folders, you will still have the possibility to continue using them, but you should seriously consider an exit strategy, because public folders are not likely to get any attention from Microsoft in the long run.

Microsoft touched the tip of information life-cycle management with Exchange 2007 with the use of managed folders. These will provide great assistance for environments where you wish to keep email for compliance purposes, yet not clutter users' mailboxes. The data are still preserved in the Microsoft Exchange databases, but a special area is created to host messages and items that are governed by a retention policy (Figure 1-2).

Exchange 2007 administrators can create management policies that define how long content can exist in user folders and whether content within that folder should deleted or journaled. These policies can be established on standard folders or custom (as defined by an administrator) folders. Custom folders are provisioned in the user's mailbox and are useable via Outlook 2003 SP2, Outlook 2007 and Outlook Web Access. They are just like any other folder except they cannot be deleted, unless the administrator decides to no longer manage them.

Messaging records management is therefore a way for administrators to comply with corporate policies for message retention and lifecycle. As you deploy this function, you will have to be careful about the overhead, both from a transactional standpoint (incurred by the action of moving messages, scanning mailboxes or deleting messages) and from a capacity standpoint: keeping messages around can bust your users' mailbox quota and lead to further problems in Outlook 2007 cache mode. Because the Outlook 2007 cache is based on PST technology (but called an OST), it suffers from the same "issues" found with large PSTs: an excessive number of I/O requests are required each time you add, delete, or modify items in the OST, every time you browse folders, or perform information scanning and retrieval. The result is a degraded user experience, and until Microsoft improves the local cache technology in Outlook, we suggest keeping the mailbox size to approximately 2GB.

The real novelty brought by Exchange 2007 is the database replication: the ability to continuously, although with a slight delay, keep a replica of a database up-to-date, and use that replica in case the source database fails. Think of it as a log shipping mechanism, except that it is fully integrated in the product, with proper instrumentation (e.g., using PowerShell), monitoring, and ease of use. It means that if you are ready to double your storage capacity, you can bring your messaging service to new levels of availability and possibly amend backup and recovery policies in a way you never imagined for an Exchange server (e.g., daily differential weekly full).

The result is that the best practices for storage that we used with previous releases of Microsoft Exchange must now be revisited, because Microsoft changed the product, and also because the industry has made progress in certain compartments of storage technology.

In summary

Thus, we take you on a journey for designing the best storage solution for your environment. Remember that what is best for you today may not be optimal 3 years from now and may not be for a company equivalent to yours. That's a challenge relevant to our industry, that is, the fact that we deal with changing technology, and that storage as we know it today will probably be significantly different 5 years from now from both technology and functionality standpoints.

The important matter is to solve your business requirements with the most appropriate technology and implementation, and to conform to best practices.

Exchange 2007 Server Roles and Usage of Storage

Figure 1-3 describes the server roles for Exchange 2007 at RTM. With Exchange 2007 SP1, you can now run Microsoft Exchange on Windows Server 2008, in addition to Windows Server 2003 SP1 and later.

In this section, we review the storage requirements for each of the roles.

Common requirements

Whatever the role of your server, you will need to provide a boot volume to the Windows operating system. The purpose of the system disk is to host the binaries of the operating system and applications, and to host the page file, which allows for virtual memory management on Windows. Little performance is required from system disks on Windows and Exchange servers. There is no significant paging activity because the Microsoft Exchange database engine will ensure using physical memory as it becomes available. If the server gets low on physical memory, Exchange will proceed to decrease its utilization of physical memory. This is particularly true for the mailbox role. It can apply as well to other roles, such as the Hub Transport Server role that will make full use of RAM for caching messages during transfer, thus preventing slow storage access. Of course, if you use complementary software to your Exchange 2007 server setup, such as a file system antivirus, a backup application, or any kind of monitoring software, you will need to ensure that indeed the system is not paging excessively. This can be monitored quite easily using the Windows performance monitor that we discuss in Chapter 11.

It's generally a good idea to have ample room on your system disk. Given the rather large size of disks, a disk fill-up condition on Windows servers these days is a pretty nasty situation to explain to your manager. You can't get disks smaller than 72GB? Fine! Make use of them and create partitions for the operating system that prevent file fragmentation and disk-full events, and comply with your crash dump management and performance monitoring policies. You might also want to break this 72GB mirror set in two or more partitions in order to create separation between vital system storage and storage that the system needs but will not cause downtime in case it gets full. For example, we frequently recommend to our customers to create a separate partition of the Windows Event and Internet Information Server log files.

Mailbox server storage

Mailbox servers are by far the most important role in an Exchange 2007 deployment when it comes to storage design. The purpose of mailbox servers is to hold a number of databases (50 maximum per server), and each database holds the mail for mailboxes homed to that database. The structure of the database is a series of tables (Figure 1-4) that contain the following:

* The list of the mailboxes

* For each mailbox, the list of folders

* For each folder, the list of messages or items

* For each message or item, a list of body part, attributes, and attachments

There is no hard-coded limit to the number of mailboxes, folders, or items that can be stored in an Exchange database. There are some practical limits, such as the number of items in the critical path folders. The critical path folders are Inbox, Calendar, Sent Items, and Contacts. These folders are used regardless of the user being connected (Inbox and Calendar) or for sending email. If you have too many items (5000 or more), the server will start getting more load than usual, and the user experience for normal operations will be degraded due to the large number of items in the folder. The size of the items is not important: it is the count that matters. You can have a very large number of items in a folder (e.g., 15,000 emails) as long as you do not use this folder often. If you have so many items in your Inbox, every time a message is delivered to you, it will cause more I/O to the database. Opening your client will also cause a larger than usual count of I/O requests. The net result is a larger footprint of Microsoft Exchange on your storage subsystem, where you will obtain two to three times more I/O per second than if you had proper maintenance.


Excerpted from Designing Storage for Exchange 2007 SP1 by Pierre Bijaoui Juergen Hasslauer Copyright © 2008 by Elsevier, Inc.. Excerpted by permission of Digital Press. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Read More Show Less

Table of Contents

Chapter 1: Introduction to Exchange 2007 Storage
Chapter 2: Basic Concepts of I/O Systems
Chapter 3: Storage Technologies
CHapter 4: Windows Storage
Chapter 5: Designing Your Exchange 2007 Server
Chapter 6: Exchange Server 2007 Failover Clustering
Chapter 7: Data Replication Solutions for Exchange
Chapter 8: Backup
Chapter 9: Recovery
Chapter 10: Storage Design Validation
Chapter 11: Performance Monitoring and Analysis
Chapter 12: Best Practices and Sample Configurations

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)