When you are transitioning from a legacy Exchange version to either Exchange 2007 or Exchange 2010 you will come to a stage in the project at which you need to plan for the migration of mailboxes to the new servers.

In small to medium size businesses the considerations are fewer than for larger enterprises, but they do share several in common.  Generally speaking you should plan for the following items.

End user interruption – when a mailbox is moved the end user will be disconnected from it.  Older versions of Outlook do not handle this very well, but even newer versions will need the end user to restart the application to connect to their new mailbox.

This means that it is often best to schedule migrations to occur outside of normal business hours.  Evenings and weekends are very common for this.  If a business operates 24 hours a day using rotating shifts then you can schedule migrations to occur so that a given user is moved when they are not rostered on duty.

Transaction Logging – a mailbox migration means that on the target server (the new server) a whole bunch of new data is being written into the databases.  This creates a very large amount of transaction logging, often much larger than what a normal day’s email traffic would generate.

There are a few ways to manage this.  Moving mailboxes in smaller batches keeps logging to a minimum but means migrations will take longer.  Provisioning large amounts of disk space on the logging volume means bigger batches can be migrated, but after the migration is finished it can mean wasted disk space that is not needed for day to day logging levels. Continue reading Planning Considerations for Exchange Mailbox Migrations

In most businesses the topic of shared email and other mailbox features will come up at some stage.  A business will have certain requirements that the Exchange administrator needs to configure the system to meet.  Depending on what those requirements are the actual configuration used will vary.

One of the most common situations is the sharing of email addresses.  A group of uses need to receive email sent to a certain email address other than their own personal email address.

Sometimes it is appropriate for this to be achieved simply by using a secondary email address on the user’s mailbox.  John Smith can have john.smith@company.com as his primary email address, but also receive email sent to his predecessor’s email address of greg.jones@company.com.

In other cases this does not work so well.  A reception desk staffed by more than one person throughout the week makes it impossible to assign reception@company.com as a secondary email address to each individual person’s mailbox, because an email address can only exist on one mail-enabled object in the organization at any one time.

The solution here could be to use a distribution group, or to use a shared mailbox.  Each has its pros and cons.  A distribution group delivers each mail item sent to the address to each member of the group.  This works fine for newsletters, memos, and other broadcast type information, but not so well for items where only one person needs to take action.

In those cases a shared mailbox is better suited, because it means a single instance of each actionable item and everyone who shares the mailbox can tell when something has already been actioned.  Shared mailboxes are commonly used for Help Desks and sales teams so that a single email address can be publicized and a team of people can access the mailbox to action new items. Continue reading Shared Email Address Scenarios

There have been many times in the past when I have started a project for a new customer and discovered that they are not using SSL for their email servers.  Usually after a brief discussion they agree to implement SSL in the new system we are installing for them.

Occasionally they agree but insist on doing it in a less than ideal manner.  And sometimes, although rarely, they decline our advice and continue without SSL.

What is SSL?

SSL stands for Secure Socket Layer and is an encryption protocol that secures communications between two parties over insecure networks such as the internet.  Although still commonly referred to as SSL its new name is actually TLS (Transport Layer Security) which more accurately describes its role of securing communications at the Transport layer of the OSI model (eg, the TCP protocol).

In an SSL/TLS secured communication the two parties (e.g. a web server and a web browser) agree on how to secure the connection they are establishing. Continue reading The Importance of SSL for Exchange Servers

There are many applications that can be affected by a server’s paged pool size. Applications such as Exchange server can report problems if the page pool size is not large enough to support the large number of user connections that are common in enterprise environments.

Sometimes Exchange server can be impacted if there is not enough paged pool memory. So what exactly is paged pool memory and how do you solve problems associated with a lack of paged pool memory?

One of the steps that occur at boot up time is the creation of memory pools. Two dynamically sized memory pools are created by the memory manager and it is those two memory pools that are used by applications during execution. Kernel-mode components use the two pools to allocate memory for the processes that are running. Those two pools are called the Paged Pool and the Non-Paged Pool.

The size of the physical memory helps in determining the initial sizes of each of those two pools at boot up. The pools are dynamic and so can grow in size over time up to a pre-determined maximum.

So how do the pool sizes affect the execution of Exchange?

Continue reading Troubleshooting Paged Pool Memory in Exchange Server

In a recent post I discussed the various factors that must be considered when planning an Exchange database design.

For Exchange Server 2003 and 2007 the layout and naming of databases played an important role in the ease of administration as well as the balancing of database load.  If Help Desk staff randomly chose a database to host a given mailbox it could easily lead to unbalanced servers and result in poor performance of the Exchange back end.

Fortunately Exchange Server 2010 makes this a lot simpler thanks to several improvements and new features.

Database Performance Improvements

An immediate improvement in Exchange 2010 is the database performance, when viewed in the context of disk IOPS (Inputs/Outputs per Second) required to perform certain operations.  Simply put, a given operation in Exchange 2010 (let’s say a user sorting their 10,000 item inbox by name instead of date) generates far less read/write load on the disks that store that mailbox database.

The benefit of this is an increase in the potential mailbox density per database.  You can fit more mailboxes into a single database, and that database can be much bigger than in previous versions of Exchange (up to 2 terabytes instead of prior recommended maximums of 100 gigabytes).

Fewer databases leaves fewer choices for Help Desk administrators when creating new mailboxes, which is a good thing.

Mailbox Load Balancing

A new feature of Exchange Server 2010 is the mailbox provisioning load balancer.  This acts as an automatic distributor of new mailboxes between mailbox databases in the organization. Continue reading Exchange Server 2010 Simplifies Mailbox Database Design

In my last post I wrote about scaling Transport servers to meet the growing needs of an organization.  In this post I will look at the same topic for Client Access servers.

Client Access Servers

The role of the Client Access server for Exchange Server 2007 is to accept all non-MAPI client connections and communicate on their behalf with the appropriate mailbox server.

An example of this would be Outlook Web Access, where a user connects with their web browser to a webmail interface on the Client Access server instead of directly to their mailbox using the full Outlook client.

The Availability Service is another example of Client Access server functionality.

Most of the traffic that Client Access servers process uses SSL encrypted connections.  Encrypted traffic requires more processing resources than non-encrypted traffic.  This means that the most important resource for a Client Access server will be the processors, however memory and disk performance also play a role and can cause bottlenecks if not appropriately sized.

Processor Scaling

A Client Access server is recommended to start with at least 4 processor cores, but very smaller environments can perform well with just 1 or 2 cores, even with multiple server roles consolidated onto a single server.

A single server can scale up to 6 processor cores if necessary to handle load.  It is not recommended to scale beyond 6 cores per server.  If processor bottlenecks are found with 6 cores it is time to scale out to more Client Access servers.

Memory Scaling

For Windows servers memory is important for caching of data for fast access by the processors.  Insufficient memory would lead to excessive page file usage on the server and higher disk I/O, slowing the server down. Continue reading Scaling Up vs Scaling Out Exchange Server 2007 Roles Part 2 – Client Access Servers

In previous posts I have talked about situations where your end users are unable to send or receive email messages under different scenarios. I also posted about the various solutions to those problems. There are a variety of problems and conditions which can create these situations.

One situation where your end users cannot receive email messages but are able to send email involves the configuration of the Exchange server.

Sometimes your end users will come to you and say that they have received the following error message when they try to connect to send email from Outlook or a POP3 (Post Office Protocol) client:

“Messages can be received but not sent. SMTP server unavailable.”

(SMTP stands for Simple Mail Transfer Protocol and is a well known email industry standard. SMTP is used for outgoing mail transport and uses port 25.)

They may also get a variant of that error message such as:

“An unknown error has occurred. Account: ‘SMTP’, Server: ‘Servername’, Protocol: SMTP, Server Response: ‘421 incorrect.domain.com connection limit reached’, Port: 25, Secure(SSL): No, Server Error: 421, Error Number: 0×800CCC67 “

Sometimes you will also see an IP address. The SMTP address, server name and IP address will be different and depend on how your Internet Service Provider (ISP) and email server have been configured.

Continue reading Managing Your Inbound Connections

With more focus being placed on rapid recovery times for disaster recovery (DR) operations, much of the design, strategy, and practice work done for DR in the past has shifted more toward the high availability (HA) concept. For many businesses, an “always on, 24/7/365″ concept is key, so a recovery time of 48 hours is simply too long, and a data loss of an entire week would be catastrophic and considered a definite disaster in its own right. So, availability is now king–how do we achieve it? See my article on Virtualization, Replication, Storage and High Availability for introductory concepts on replication and how storage requirements increase, and on the general ideas behind clusters and replication.

Many of you here are from a Microsoft Exchange and therefore a Windows Server environment. While much has changed in the capabilities for Windows server clustering, especially in the Exchange area, many of the core concepts are the same regardless of what the latest features and options are. For example, block-level replication across drives on a SAN solution such as EMC’s SRDF/CE option is specifically designed to assist in replication of Windows databases such as SQL and Exchange, but the block-level replication works in essentially the same manner as DRBD does on Linux.

Continue reading Considerations for High Availability Designs Used for Disaster Recovery

That is the question that came to my mind when I was considering the career options of Exchange Server administrators.

I know that other IT professions carry varying degrees of complexity, but still wonder how often the email admin is the smartest person in the room.  Putting aside the ego behind that question there are definitely a lot of areas in which an email admin needs to have an understanding.

Let’s consider some of the technical skills that a good email admin needs.

Email Servers – often the email administrator is working in environments with more than one email server product in production.  Even those who only manage one server product will still encounter other products as they deal with outside parties, often trying to troubleshoot a mail delivery problem.

Operating Systems – the email admin is also usually responsible for the operating system running on the server.  Again in heterogeneous environments this may mean several different editions of Microsoft Windows as well as some form of Linux or Unix.

High Availability – larger environments often require high availability for their email systems.  This means the email admin needs to understand cluster, network load balancing, and the Exchange Server high availability features.

Firewalls – every email system needs to move data to and from the internet, so an understanding of firewalls from different vendors is necessary.

DNS – this plays an important role in several ways, not only the MX records but also concepts such as split DNS and how important reverse DNS is for delivery. Continue reading Are Email Admins the Smartest People in the Room?

I’m working with a customer at the moment who has a few problems with their Exchange Server environment.  Most of the problems stem from explosive growth in staff numbers without all of the right standards and procedures in place to ensure that the Exchange system would scale upwards and continue delivering the required KPIs.

One of the problems is an unbalanced distribution of mailboxes across the various mailbox databases on the Exchange servers.  The reason for this is quite simple – each of the mailbox databases is given a name along a standard, but this name gives no indication as to which mailboxes should be placed on it.  In fact there is no system in place to determine where a given mailbox should reside.

As a result of this whenever a new mailbox is created it is placed at random onto one of the mailbox databases.  After a few years of this practice we can see that some databases have just a few dozen mailboxes in them, whereas others have thousands of mailboxes in them.

Unbalanced Database Problems

An unbalanced distribution of mailboxes such as this can cause some serious problems, such as:

• Excessive I/O load on some databases and their back-end storage
• Databases well in excess of recommended maximum sizes
• Long backup and recovery times for the larger databases
• Long maintenance times on the larger databases

A more efficient database layout needs to be designed and implemented to resolve these issues.

Design Considerations

Designing a database layout for an Exchange system takes some careful planning and consideration of the characteristics of the business and network environments.  There is no ‘one size fits all’ approach to this.  As I discussed the matter with my colleagues, these are some of the factors we took into consideration:

• Geographical location of the mailbox servers
• Limitations of the Exchange Server product version in terms of maximum allowed databases
• Mailbox storage quotas, for example VIPs have 2Gb limits but staff have 500Mb limits
• Current size and likely growth of the business in terms of staff numbers
• Maximum recommended database sizes from Microsoft
• Maximum practical database sizes to achieve backup and recovery timeframes
• Naming convention that makes it simple for IT admins to select a mailbox database for new mailboxes

The first consideration is an easy one.  It goes without saying that if mailbox servers are dispersed among the major geographical locations of the business then mailboxes should be placed on the closest server to the user.  So for example, North America users will be placed on server located on that continent, and the database naming convention will include an indicator such as “NAM” or “NAM-East”. Continue reading Designing an Exchange Server Database Layout