Applications Server

Exchange Server 2010 Mailbox Services Configuration (part 1)

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
10/17/2010 5:14:28 PM
Much of the configuration that is done for the Mailbox server role is done during the hardware configuration and installation of the Mailbox role. After the Mailbox role is installed, creating and configuring databases usually completes most of what needs to be done. After the deployment is completed, management of mailboxes and public folders is usually the extent to which the Mailbox server is managed. When you install Exchange, you need to consider a number of important things.

One of the biggest considerations is where Exchange should be installed and how the disks should be configured for the databases. As best practice it is always good to have the operating system and the system page file configured on separate RAID1 or RAID10 disks.

As with Exchange Server 2007, each database needs to be located on the same path on each server that will host a copy. When deploying a DAG with more than 22 different databases, managing drive letters might be a challenge. Rather than assigning each drive a new letter, they should be assigned mount points on a RAID-protected volume. Following this best practice will allow more than 24 disks to be used and provide flexibility to remount a replacement disks to that mount point quickly in case of a failure. If the disk that hosts the mount points fails, the mount points will also become unavailable. Protecting the mount point host volume with RAID will ensure that a single disk failure will not cause all of the databases to go offline.

This chapter has covered a number of the storage improvements that have been made in Exchange Server 2010. These changes affect all aspects of design and should cause experienced Exchange administrators to reconsider a lot of the accepted assumptions that have become rote. One of these is the need to ensure that the transaction logs and the database must be on separate physical disks. With the lower I/O requirements and database write smoothing, this no longer becomes a problem with disk contention. There are still reasons that it might be good to split the transaction logs and databases on separate volumes or disks. One such reason is to not allow growing transaction logs to run the disk out of space and cause the database to go offline. In a stand-alone deployment it is still important to store the transaction logs on separate disks from the database so that in the event of a disk failure, both the transaction logs and the database are not lost. In a high-availability deployment, multiple copies of the data already exist on other servers.

Notes From The Field: Segregating Database and Transaction Logs

Thierry Demorre

Senior Director, Infrastructure Services Line, East Operating Unit, Avanade Inc.

Placing Exchange database files and transaction logs on disk has always been a subject of discussion between Exchange design engineers and the storage engineers. Usually the former wanted to split those files across different physical disks while the latter preferred a single large aggregate and lay out all of those files together. Exchange Server 2010 provides a simple solution to this design argument thanks to two major improvements over previous Exchange versions: DAGs and a new I/O profile.

Database Availability Groups

Three or more copies of a database means more redundancy than in a typical RAID 1 or RAID 5 configuration, which is enough redundancy for your database and transaction log files. In the event of a failure of one of the instances, the remaining data is not affected. Therefore, having the database and transaction log files sharing the same physical disks should not be a concern.

Extensible Storage Engine (ESE) I/O Profile

The ESE went through a major overhaul in the way it handles disk writes. All of the previous versions of Exchange have always written small, random blocks of data. Now, ESE has been optimized for large sequential writes, which from a disk activity perspective translates to most database writes being sequential. Because transaction log writes are also sequential, mixing those two I/O profiles on the same physical disks will not affect the scaling capability.

1. Determining the Number of Mailboxes for Each Server

A number of factors go into deciding the number and size of mailboxes that should be placed on a single server and how to configure the number of mailboxes that should be placed in each database. The final decision will weigh several key factors, such as the size, relative importance, and, most important, the service level agreement (SLA) required for the mailboxes.

Although 10,000 mailboxes provided to university students with a maximum quota size of 25 MB at no cost may take up more space than 250 executives with a maximum quota of 10 GB, the former mailboxes are arguably far less important. Weigh this relative importance against the number of mailboxes that can be recovered within the SLA. When it comes down to it, database size is often governed by your redundancy design.  In both of these areas improvements have been made to reduce the need and improve the speed of recovery should it be required. With these changes and careful planning it usually is possible to increase the size that the databases should be allowed to grow.

Notes From The Field: How Many Mailboxes Should Be Created on a Server?

Thierry Demorre

Senior Director, Infrastructure Services Line, Avanade Inc.

Two of the most common questions about Exchange are "How many mailboxes can I fit on this server?" and "With this new version of Exchange, will we get twice as many mailboxes on a server than in the previous version?" Unfortunately, these questions have no definitive answers, because of a number of contributing factors to both the performance and the space requirements for an Exchange mailbox server. These are the two principle factors to take into consideration for appropriately sizing an Exchange Mailbox server.

Actually, asking how many mailboxes can be hosted on a server is not the correct question. A better way to approach the question would be to ask, "How many 1-GB mailboxes, with a medium profile usage, having a 90 KB average message size, with single item recovery configured for 20 days and calendar versioning can I host on my server with 16 cores that run at 3.4G Hz and have 32 GB of RAM and are connected to 48, 1-TB-large form factor 10,000 RPM SAS hard drives?" Although the qualification statement is wordy, it does properly identify the target usage for the mailboxes. Having this level of detail when asking this question will provide a better basis for answering the question using the right tools.

The best practice here really is two-fold: first you need to understand what you are sizing for, and second you need to validate your assumptions against the Mailbox Server Role Requirements Calculator published by the Exchange product group. To do the former you must investigate the current environment and profile the users that will be migrated or transitioned to the new environment. To do the latter you should download and learn to use the calculator. The calculator takes extensive testing done by the product group and wraps it into a fairly simple Microsoft Office Excel spreadsheet. This calculator should be the starting point at any serious Exchange design. After gauging the configuration sizing using the calculator you should use the information you have gathered to configure tools such as JetStress and Load Simulator to prove the calculations are correct.

After verifying the number of mailboxes that can be hosted on the configured servers, the last question that needs to be answered is how many is too many? As the number of mailboxes on a server grows, the number of users that would be affected in the event of a single server outage or degradation of service increases. Employing high-availability best practices can curb many of these problems; however, there is still risk in placing too many mailboxes on a single server rather than scaling out the same number of users across multiple servers.

2. Determining Where to Host Mailboxes

A number of best practices are defined for placing mailbox servers and mailboxes on these servers. As you define the location of each of your user populations, the network connectivity, server and storage capabilities, and skill sets available at each site, where to place the servers may become clearer.

Several configurations are used to define the configuration, as seen in the example solutions used in this book. The Litware deployment is a distributed environment with Exchange mailbox and other services pushed out to the remote sites. This has several advantages, especially if the users at the remote offices primarily communicate with each other. Because users primarily communicate with each other, the majority of the e-mail messages stay within the site and do not need to traverse the network. The side benefit of this is that in the event of network issues where the remote site loses connectivity back to one of the corporate sites, the local users can continue to send and receive e-mail. The downside of this configuration is that support for the remote servers can be challenging especially if physical access is needed to repair the hardware.

The Fabrikam deployment uses a more centralized deployment. The benefit of this type of deployment is that mailbox services are concentrated in locations that have appropriate network connectivity and support staff to handle monitoring and maintenance of the hardware and software.

The best practice for determining where to host mailboxes depends on what fits the business requirements, network requirements, and administrative requirements. The principle should always be to keep the design as simple as possible while still achieving the goals. You need to ask several key questions when determining where to host mailboxes:

  • Is there adequate and redundant bandwidth available between the clients and the Exchange servers?

  • If the Exchange servers will be hosted at a remote location, how will backups, hardware maintenance, and monitoring be accomplished?

  • Does the remote site have adequate power, cooling, and network connectivity?

Other -----------------
- Exchange Server 2007: Monitor Your Exchange Environment (part 4) - Microsoft Operations Manager (MOM 2005)
- Exchange Server 2007: Monitor Your Exchange Environment (part 3) - Performance Troubleshooter
- Exchange Server 2007: Monitor Your Exchange Environment (part 2)
- Exchange Server 2007: Monitor Your Exchange Environment (part 1)
- Use the Exchange 2007 Toolbox to Troubleshoot
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us