1. Exchange Server 2010 and Your Hardware
Before you deploy Exchange Server 2010, you should carefully plan the messaging architecture. As part of your implementation planning, you need to look closely at preinstallation requirements and the hardware
you will use. Exchange Server is no longer the simple messaging server
that it once was. It is now a complex messaging platform with many
components that work together to provide a comprehensive solution for
routing, delivering, and accessing e-mail messages, voice-mail messages,
faxes, contacts, and calendar information.
Successful Exchange Server administration depends on three things:
Key guidelines for choosing hardware for Exchange Server are as follows:
Memory
Exchange Server 2010 has been tested and developed for maximum memory
configurations of 64 gigabytes (GB) for Mailbox servers and 16 GB for
all other server roles except Unified Messaging. For Unified Messaging,
the maximum is 8 GB. For multirole servers, the maximum is 64 GB. The
minimum random access memory (RAM) is 2 GB. In most cases, you'll want
to have at least twice the recommended minimum amount of memory. The
primary reason for this is performance. Most of the Exchange
installations I run use 4 GB of RAM as a starting point, even in small
installations. In multiple Exchange server installations, the Mailbox
server should have at least 2 GB of RAM plus 5 megabytes (MB) of RAM per
mailbox. For all Exchange server configurations, the paging file should
be at least equal to the amount of RAM in the server plus 10 MB.
CPU
Exchange Server 2010 runs on the x64 family of processors from AMD and
Intel, including AMD64 and Intel Extended Memory 64 Technology (Intel
EM64T). Exchange Server 2010 provides solid benchmark performance with
Intel Xeon 3.4 GHz and higher or AMD Opteron 3.1 GHz and higher. Any of
these CPUs provide good starting points for the average Exchange Server
system. You can achieve significant performance improvements with a high
level of processor cache. Look closely at the L1, L2, and L3 cache
options available—a higher cache can yield much better performance
overall. Look also at the speed of the front-side bus. The faster the
bus speed, the faster the CPU can access memory.
Exchange Server 2010 runs only on 64-bit hardware. The primary advantages of
64-bit processors over 32-bit processors are related to memory
limitations and data access. Because 64-bit processors can address more
than 4 GB of memory at a time without physical address extension, they
can store greater amounts of data in main memory, providing direct
access to and faster processing of data. In addition, 64-bit processors
can process data and execute instruction sets that are twice as large as
32-bit processors. Accessing 64 bits of data (versus 32 bits) offers a
significant advantage when processing complex calculations that require a
high level of precision.
Note:
At the time of this writing, 64-bit versions do not support Intel Itanium.
SMP Exchange Server 2010 supports symmetric multiprocessors, and you'll see significant performance improvements if you use multiple CPUs. Microsoft tested and developed Exchange Server 2010 for use with dual-core and multicore CPUs as well. The minimum, recommended, and maximum number of CPUs—whether single core, dual core, or multicore—depends on a server's Exchange roles. Still, if Exchange Server is supporting a small organization with a
single domain, one CPU with multiple cores should be enough. If the
server supports a medium or large organization or handles mail for
multiple domains, you might want to consider adding processors. When it
comes to processor cores, I prefer two 4-core processors to a single
8-core processor given current price and performance tradeoffs. An
alternative is to distribute the workload across different servers based
on where you locate resources.
Disk drives
The data storage capacity you need depends entirely on the number and
size of the data that will pass through, be journaled on, or stored on
the Exchange server. You need enough disk space to store all data and
logs, plus workspace, system files, and virtual memory. Input/output
(I/O) throughput is just as important as drive capacity. Rather than use
one large drive, you should use several drives, which allow you to
configure fault tolerance with RAID.
Data protection
You can add protection against unexpected drive failures by using RAID.
For the boot and system disks, use RAID 1 on internal drives. However,
because of the new high-availability features, you might not want to use
RAID for Exchange data and logs. You also might not want to use
expensive disk storage systems either. Instead, you might want to deploy
multiple Exchange servers with each of your Exchange roles.
If
you decide to use RAID, remember that storage arrays typically already
have an underlying RAID configuration and you might have to use a tool
such as Storage Manager For SANs to help you distinguish between logical
unit numbers (LUNs) and physical disks. For data, use RAID 0 or RAID 5.
For logs, use RAID 1. RAID 0 (disk striping without parity) offers good
read/write performance, but any failed drive means that Exchange Server
can't continue operation on an affected database until the drive is
replaced and data is restored from backup. RAID 1 (disk mirroring)
creates duplicate copies of data on separate drives; you can rebuild the
RAID unit to restore full operations and can continue operations if one
of the drives fails. RAID 5 (disk striping with parity) offers good
protection against single drive failure, but it has poor write
performance. For best performance and fault tolerance, RAID 10 (also
referred to as RAID 0 + 1), which consists of disk mirroring and disk
striping without parity, is also an option.
Uninterruptible power supply Exchange
Server 2010 is designed to maintain database integrity at all times and
can recover information using transaction logs. This doesn't protect
the server hardware,
however, from sudden power loss or power spikes, both of which can
seriously damage hardware. To prevent this, connect your server to an uninterruptible
power supply (UPS). A UPS gives you time to shut down the server or
servers properly in the event of a power outage. Proper shutdown is
especially important on servers using write-back
caching controllers. These controllers temporarily store data in cache.
Without proper shutdown, this data can be lost before it is written to
disk. Note that most write-back caching controllers have batteries that
help ensure that changes can be written to disk after the system comes
back online.
If
you follow these hardware guidelines and modify them for specific
messaging roles, as discussed in the next section, you'll be well on
your way to success with Exchange Server 2010.
2. Exchange Server 2010 Editions
Several editions of
Exchange Server 2010 are available, including Exchange Server 2010
Standard and Exchange Server 2010 Enterprise. For
reference, the specific feature differences between Standard Edition and Enterprise Edition are as follows:
Exchange Server 2010 Standard
Designed to provide essential messaging services for small to
medium-size organizations and branch office locations. This server
edition supports a limited number of databases.
Exchange Server 2010 Enterprise
Designed to provide essential messaging services for organizations with
increased availability, reliability, and manageability needs. This
server edition supports up to 100 databases (including all active
databases and copies of databases) on a particular server.
REAL WORLD Microsoft provides a single binary for x64 systems, and the same binary file is used for both the Standard and Enterprise edition. The license key provided during installation is what determines which edition is established during installation.
You can use a valid product key to upgrade from a trial edition to the Standard edition or the Enterprise edition of Exchange Server 2010 without having to reinstall. Using a valid product
key, you can also upgrade from the Standard to the Enterprise edition.
You can also relicense an Exchange server by entering a new product
key for the installed edition, which is useful if you accidentally used
the same product key on multiple servers and want to correct the
mistake.
There are several caveats. When
you change the product key on a Mailbox server, you must restart the
Microsoft Exchange Information Store service to apply the change. When
you change the product key on an Edge Transport server, you must
resubscribe the server in the Exchange organization to apply the change.
Additionally, you cannot use product keys to downgrade editions. To downgrade editions, you must uninstall Exchange Server and then reinstall Exchange Server.
You can install
Exchange Server 2010 on a server running Windows Server 2008 with
Service Pack 2 or later as well as on a server running Windows Server
2008 Release 2. A client accessing an Exchange server requires a Client Access License (CAL). With either Exchange Server edition, the client can use a Standard CAL, an Enterprise
CAL, or both. The Standard CAL allows for the use of e-mail, shared
calendaring, contacts, task management, Microsoft Outlook Web App (OWA),
and Exchange ActiveSync. The Enterprise CAL allows for the use of
unified messaging, advanced compliance capabilities, and
antivirus/antispam protection. A client must have both a Standard CAL
and an Enterprise CAL to make full use of all Exchange Server features.
Beyond the editions and CALs, Exchange Server 2010 has several variants. Microsoft offers on-premises and online
implementations of Exchange Server. An on-premises Exchange Server is
one that you install in your organization. An online Exchange Server is
delivered as a subscription service from Microsoft. In Exchange Server
2010, you can manage both on-premises and online implementations of
Exchange Server using the same management tools.
When you install Exchange
Server 2010, the system partition and all disk partitions used by
Exchange must be formatted using the NTFS file system. Additional preinstallation requirements are as follows:
In the Active
Directory forest where you plan to install Exchange 2010, the Schema
master must be running on a server with Windows Server 2003 or a later
version of Windows and Active Directory must be in at least Windows
Server 2003 forest functionality mode.
In
every Active Directory site where you plan to install Exchange 2010,
you must have at least one global catalog server that is running Windows
Server 2003 or a later version of Windows.
For
forest-to-forest delegation and free/busy availability selection across
forests, you must establish a trust between the forests that have Exchange Server installed.
The domain should be configured to use multiple-label Domain Name System (DNS) names, such as cpandl.com or adatum.local, rather than single-label DNS names, such as cpandl or adatum. However, single label names can be used.
Exchange Server 2010 requires Microsoft Management Console 3.0 or later, the Microsoft .NET Framework version 3.5.1, and Windows PowerShell Version 2.0 for the Exchange Management Shell and remote management. The Windows PowerShell remoting features are supported by the WS-Management
protocol and the Windows Remote Management (WinRM) service that
implements WS-Management in Windows. Computers running Windows 7 and
Windows Server 2008 Release 2 and later include WinRM 2.0 or later. On
computers running earlier versions of Windows, you need to install
Windows Management Framework, which includes Windows PowerShell 2.0 and
WinRM 2.0 or later as appropriate.
If you want to manage
Exchange Server 2010 from a workstation, you need to install Windows
Management Framework. Because WinRM 2.0 and Windows PowerShell 2.0 are
used for remote management whether you use the GUI or the command line,
you need to enable remote commands on the workstation.
You can verify the availability of WinRM 2.0 and configure Windows PowerShell for remoting by following these steps:
Click
Start, All Programs, Accessories, Windows PowerShell. Start Windows
PowerShell as an administrator by right-clicking the Windows PowerShell
shortcut and selecting Run As Administrator.
The
WinRM service is configured for manual startup by default. You must
change the startup type to Automatic and start the service on each
computer you want to work with. At the PowerShell prompt, you can verify that the WinRM service is running by using the following command:
get-service winrm
As shown in the following example, the value of the Status property in the output should be Running:
Status Name DisplayName
------ ---- -----------
Running WinRM Windows Remote Management
If the service is stopped,
enter the following command to start the service and configure it to
start automatically in the future:
set-service -name winrm -startuptype automatic -status running
To configure Windows PowerShell for remoting, type the following command:
Enable-PSRemoting -force
You can only enable
remoting when your computer is connected to a domain or private network.
If your computer is connected to a public network, you need to
disconnect from the public network and connect to a domain or private
network and then repeat this step. If one or more of your computer's
connections has the Public connection type, but you are actually
connected to a domain or private network, you need to change the network
connection type in Network And Sharing Center and then repeat this
step.
In many cases, you will be able
to work with remote computers in other domains. However, if the remote
computer is not in a trusted domain, the remote computer might not be
able to authenticate your credentials. To enable authentication, you
need to add the remote computer to the list of trusted hosts for the local computer in WinRM. To do so, type the following:
winrm s winrm/config/client '@{TrustedHosts="RemoteComputer"}'
where RemoteComputer is the name of the remote computer, such as:
winrm s winrm/config/client '@{TrustedHosts="CorpServer56"}'
When you are working with computers in workgroups
or homegroups, you must use HTTPS as the transport or add the remote
machine to the TrustedHosts configuration settings. If you cannot
connect to a remote host, verify that the service on the remote host is
running and is accepting requests by running the following command on
the remote host:
winrm quickconfig
This command analyzes and configures the WinRM service. If the WinRM service is set up correctly, you'll see output similar to the following:
WinRM already is set up to receive requests on this machine.
WinRM already is set up for remote management on this machine
If the WinRM service is not set
up correctly, you see errors and need to respond affirmatively to
several prompts that allow you to automatically configure remote
management. When this process completes, WinRM should be set up
correctly.
Whenever you use
Windows PowerShell remoting features, you must start Windows PowerShell
as an administrator by right-clicking the Windows PowerShell shortcut
and selecting Run As Administrator. When starting Windows PowerShell
from another program, such as the command prompt (cmd.exe), you must
start that program as an administrator.
Exchange Server 2010 uses the Windows Installer (the Installer) and has a fully integrated installation process. This means you can configure Exchange
Server 2010 much like you can any other application you install on the
operating system. The installation can be performed remotely from a
command shell as well as locally.
With an initial installation, Windows Installer first checks the system configuration to determine the status of
required services and components. As part of this process, Windows
Installer checks the Active Directory configuration and the availability
of components, such as IIS (Internet Information Services), as well as
operating system service packs, installation permissions for the default
install path, memory, and hardware.
After checking the
system configuration, the Installer allows you to select the roles to
install. Whether you use the Standard or Enterprise edition, you have
similar options. You can do any of the following:
Install an internal messaging server by selecting the individual server
roles to install and combining the Mailbox role, Client Access role,
Hub Transport role, and Unified Messaging role as required for your
environment. Generally, you will not want an internal Exchange server to
also be configured as a domain controller with a global catalog.
Note:
Before you install the Client Access role on servers with
the Mailbox role, you'll want to consider whether you want to use client
access arrays. A client access array is a grouping of client access
servers in a load balanced array. Servers that are members of the array
cannot have the Mailbox role.
Install
a Messaging server in a perimeter zone outside the organization's main
network by selecting only the Edge Transport role. Edge Transport
servers are not members of the internal Active Directory forest and are
not configured on domain controllers. They can, however, be members of an extranet Active Directory forest, which is useful for management purposes.
Install the management tools.
Specify the path for the Exchange Server installation files.
Specify the path for the Exchange Server installation.
If you want to change the
configuration after installation, you can use Exchange Server 2010
maintenance mode.
Exchange Server 2010 includes the following antispam and antivirus capabilities:
Connection filtering Allows administrators to configure IP Block lists and IP Allow lists, as well as providers who can supply these lists.
Content filtering
Uses intelligent message filtering to scan message content and identify
spam. Spam can be automatically deleted, quarantined, or filed as junk e-mail.
Tip:
Using the Exchange Server management tools, administrators can manage messages sent to the quarantine
mailbox and take appropriate actions, such as deleting messages,
flagging them as false positives, or allowing them to be delivered as
junk e-mail. Messages delivered as junk e-mail are converted to plain
text to strip out any potential viruses they might contain.
IP reputation service Provides Exchange Server 2010 customers with exclusive access to an IP Block list provided by Microsoft.
Outlook Junk E-mail Filter list aggregation Allows the junk e-mail filter lists of individual Outlook users to be propagated to Exchange servers.
Recipient filtering
Allows administrators to replicate recipient data from the enterprise
to the server running the Edge Transport role. This server can then
perform recipient lookups on incoming messages and block messages that
are for nonexistent users, which prevents certain types of attacks and
malicious attempts at information discovery.
Sender ID verification
Verifies that incoming e-mail messages are from the Internet domain
from which they claim to come. Exchange verifies the sender ID by
examining the sender's IP address and comparing it to the related
security record on the sender's public DNS server.
Sender reputation scoring
Helps to determine the relative trustworthiness of unknown senders
through sender ID verification and by examining message content and
sender behavior history. A sender can then be added temporarily to the
Blocked Senders list.
Although these antivirus
and antispam features are extensive, they are not comprehensive in
scope. For comprehensive antivirus protection, you need to install Forefront Protection for Exchange Server. Forefront
Protection for Exchange Server helps protect Exchange servers from
viruses, worms, and other malware using multiple antivirus scan engines
and file-filtering capabilities. Forefront
Protection provides distributed protection for Exchange servers with
the Mailbox server, Hub Transport server, and Edge Transport server
roles. Although you can install Forefront Protection on Exchange servers
with these roles to gain substantial antivirus protection, you do not
need to install Forefront Protection on Exchange servers with only the
Client Access server or Unified Messaging server role.
You can
use the Forefront Protection Setup program to install the server and
management components. The management components include the Forefront
Server Security Administration Console and the Forefront Management
Shell. When you are working with the console, you can configure the way
real-time and scheduled scanning for viruses and spyware works. In the
shell, you'll find Forefront-specific cmdlets for performing similar
tasks.
