Microsoft has simplified the process for installing the Exchange Server product, and Exchange Server 2003 is the easiest-to-install Exchange version to date. However, it's important to understand the steps leading to a successful installation so that any appropriate planning or preparation is done prior to the live installation. Plus, because Exchange Server 2003 includes many new functions that extend beyond basic e-mail messaging and calendaring, getting the first Exchange 2003 server installed properly sets the foundation for a successful enterprise rollout of the Exchange messaging system. This sample book chapter will help you get your head screwed-on straight.

This
chapter
explains
the
basic
installation
of a
new
Exchange
2003
server.
In this
latest
version
of Exchange,
Microsoft
has
taken
a big
step
in improving
the
installation
process
to make
it a
lot
more
intuitive
than
previous
versions
of Exchange.
The
tools
included
on the
installation
CD walk
you
through
the
preinstallation
tasks
to verify
the
environment
prior
to installing
the
server.

When
you
execute setup.exe,
you
are
not
launched
immediately
into
the
installation
program.
You
are
taken
through
a step-by-step
checklist
of tasks
prior
to launching
the
setup
executable.

This
chapter
does
not
present
upgrading
or migrating
from
previous
versions
of Exchange
and
other
messaging
platforms.
You
read
about
migrations
in Chapters
14, "Migrating
from
NT4
to Windows
Server
2003";
15, "Migrating
from
Exchange
5.5
to Exchange
Server
2003";
16, "Migrating
from
Exchange
2000
to Exchange
Server
2003;
34, "Migrating
from
Novell
GroupWise
to Exchange
2003";
and
35, "Migrating
from
Lotus
Notes
to Exchange
2003."

Preparing
for
Implementation
of Exchange
2003

Several tasks should be done prior to installing Exchange 2003. The choice of
running Exchange 2003 on Windows 2000 or Windows 2003 affects the
preinstallation steps that need to take place and the functionality of Exchange.
Some tasks are optional, such as forest prep and domain prep (automatically done
when setup is run), but most tasks are requirements that would stop the install
process, such as having a Global Catalog available on the network or not having
the NNTP service installed on the server where you are installing Exchange.

Implementing Active Directory

Before you install Exchange Server 2003 on your network you need to make sure
that Active Directory is properly deployed. The Active Directory infrastructure
and DNS need to be healthy and without replication errors prior to installing
your first Exchange 2003 server. It is so important to perform health checks and
verification steps in your environment prior to installation that the Exchange
development team has designed the installation program to include these steps.
Exdeploy walks you through all the preinstallation health checks before running
the setup program for Exchange 2003.

Realizing the Impact of Windows on Exchange

Because Windows is the base infrastructure for Exchange 2003, take into
account key factors prior to implementing Exchange:

Global Catalog placement

Windows Mixed versus Native Mode

Group type used

Extension of the forest schema

Preparation of the Active Directory domain

Global Catalog Placement

One item to review is the placement of Global Catalogs within the Active
Directory site configuration. The importance of the Global Catalog server cannot
be overstated. The Global Catalog is used for the address list that users see
when they are addressing a message. If the Global Catalog server is not
available, the recipient’s address will not resolve when users address a
message, and the message will immediately be returned to the sender.

One well-equipped Global Catalog server can support several Exchange 2003
servers on the same LAN segment. There should be at least one Global Catalog
server in every Active Directory site that contains an Exchange 2003 server. For
large sites, two Global Catalogs are much better and provide redundancy in the
event the first Global Catalog server is unavailable.

For optimization, plan on having a Global Catalog server close to the clients
to provide efficient address list access. Making all domain controller servers
Global Catalog servers is recommended for an organization that has a single
Active Directory domain model and a single site, and it’s also not a bad
idea for Active Directory designs that use a placeholder domain as the forest
root with one or two first-level domains. A good Active Directory site design
helps make efficient use of bandwidth in this design. This design helps reduce
some of the overhead with multiple Global Catalogs in every Active Directory
site.

The Active Directory Replication Monitor (ReplMon) can be used to help
determine the number of Global Catalogs in the Active Directory forest. To start
the Active Directory Replication Monitor, click Start, All Programs, Windows
Support Tools, Command Prompt, and then run replmon.exe. Use the Edit
menu to add a monitored server. When the server is displayed, right-click the
server and select Show Global Catalog Servers in Enterprise.

TIP

To access the Windows 2003 support tools, install them from the Windows 2003
CD. Go to the original CD, select Support, Tools, and run the
Suptools.msi installer, which installs the Windows 2003 support
utilities into the \Program Files\Support Tools\ directory.

If the domain that will host Exchange 2003 is or was in mixed mode, a message
may be displayed during domain prep saying that the domain might possibly be
insecure because of the Pre-Windows 2000 Compatible Access group. This is just a
warning, and the installation of Exchange can proceed with just the
understanding that Exchange may be insecure due to the current configuration of
the domain.

Members of the Pre-Windows 2000 Compatible Access group will be able to see
the members of groups that have their membership marked as hidden. In order to
secure group membership, users and groups must be removed from this group before
installing Exchange 2003. It is not necessary to resolve this security issue
prior to installing Exchange 2003, because the removal of objects from this
group can be done soon after Exchange 2003 has completed installation.

NOTE

Frequently, confusion occurs when Exchange implementers hear that Windows
Active Directory must be in Native Mode for the organization to be able to
implement Exchange 2003. That’s not true. As covered in Chapter 15, during
a migration from Exchange v5.5, if the destination domain is not in Native Mode,
certain public folder group attributes are not migrated properly. Workarounds
during a migration are covered in Chapter 15. However, for a clean installation
of Exchange 2003, Exchange can be implemented in a Mixed Mode domain
structure if that fits the needs of the organization.

Selecting a Windows 2000/Windows 2003 Group Model

Groups can be a big issue in Exchange 2003, especially in multidomain Windows
2000 or Windows 2003 Active Directory environments. Exchange 2003 uses Windows
2000 groups in place of the distribution lists that were used in Exchange 5.5.
Distribution lists in Exchange 5.5 have been replaced by distribution groups in
Active Directory. A Windows 2000 or Windows 2003 distribution group is the same
as an Exchange 5.5 distribution list except it cannot be assigned permissions on
an access control list. This means the strategy to secure calendars, public
folders, and resources in Exchange 5.5 has to be redesigned for Exchange 2003.
There are two major issues with groups that architects and administrators need
to be concerned about:

Visibility

Permissions

Viewing Group Membership with Visibility

Visibility enables users to view the membership of the group. This is
obviously an important requirement when sending an email to a group of users,
because the users would like to see the list of recipients to whom they are
sending the message.

Here is the way the group types affect visibility:

Domain Local—Domain membership is not in the
Global Catalog. Users in a domain can see the membership of domain local groups
only from their own domain. They can see the group entry for domain local groups
from other domains in the Global Address List (GAL), but they cannot see the
members.

Global—Domain membership is not in the Global
Catalog. Users in a domain can see the membership of global groups only from
their own domain. They can see the group entry for global groups from other
domains in the Global Address List but they cannot see the members.

Universal—Domain membership is in the Global
Catalog. Users can see the membership of the group no matter where the group
resides.

In a single domain model or a domain model that uses a placeholder for the
forest root and just one first-level domain, this issue is fairly simple to
solve. Any group model will work in this design as long as all mailbox-enabled
users reside in the same domain. If the plan is to add more domains later,
universal groups should be used because of their flexibility. Another option
would be to use domain local groups and then convert them to universal groups
after the additional domains are installed.

Permissions

Security groups are required for assigning permissions to calendars, public
folders, and resources. A security group type of domain local, global, or
universal must be selected to control permissions on objects. Because
controlling access to collaboration objects is essential, it’s best to
avoid distribution groups to reduce confusion for end-users and administrators.
If the organization is supporting multiple mail platforms, it might be forced to
support the distribution group as a representation of the foreign mail
system’s mailing list, but try to avoid using them for collections of
Exchange 2003 users.

For full functionality, the best solution is to use universal security
groups. This provides the ability to see group membership across all domains and
to assign permissions to calendars, file shares, public folders, and other
resources—all with the same group. In larger environments, there are some
obvious challenges with using universal groups that are mostly political because
of the segmentation of which group controls email, directory, and file
resources.

The second challenge with universal security groups is that the Active
Directory domain must be in native mode to support universal security groups.
This means all DCs in the domain must be running Windows 2000 or Windows 2003
Active Directory and not Windows NT 4.0.

The last challenge with using universal security groups is that they incur a
replication penalty. If the group membership changes for one user, the entire
group is replicated to all DCs in the local domain and to all Global Catalogs in
the forest. This usually does not make or break a design decision to use
universal security groups, but architects need to keep it in mind if they have
remote Global Catalogs across bandwidth-choked links. The way Active Directory
handles group membership changes might change in future revisions of the
product.

NOTE

The way Active Directory handles group membership changes could be a problem
for organizations that use in-house applications or third-party applications
that automatically rebuild Universal Security Group membership daily, depending
on list size, rebuild frequency, and the number of lists.

Although Active Directory in Windows 2000 had a practical limit of 5,000
users for a single group membership, Active Directory in Windows 2003 has
extended that far beyond 5,000 users. If very large lists are required, you can
choose to use nested lists and keep each individual list to a functionally
limited basis.

Extending the Active Directory Schema

The first step to the actual implementation of Exchange 2003 is to extend the
Active Directory schema. The schema comprises the rules that apply to
the directory and controls what type of information can be stored in the
directory. It also describes how that information is stored in the
directory—such as string, string length, integer, and so on. Exchange 2003
almost doubles the amount of attributes in the Active Directory schema.

Extending the schema is the easiest part of the installation, but it is also
the place where many organizations make mistakes. To extend the Active Directory
schema, use the /forestprep switch on setup.exe for Exchange
2003 or follow the steps outlined in the deployment tool. A few tips to note
before extending the Active Directory schema:

The schema must be extended on the server that holds the Schema Master
FSMO role. By default, the first server installed in the forest contains the
Schema Master; however, this role could have been moved to another server. To
locate which server contains the Schema Master FSMO role, use the Active
Directory Schema MMC snap-in, right-click the Active Directory Schema icon under
the console root, and select Operations Master.

TIP

To use the Active Directory Schema MMC snap-in, the adminpak.msi
file must be installed on the server. Use the run command and execute
adminpak.msi to install the adminpak. After the adminpak is installed,
open the MMC from the run prompt by executing MMC; then use the Add/Remove
snap-in option from the Console menu to add the Active Directory Schema MMC
snap-in.

The account used to extend the schema must be a member of the schema
admins group and domain admins or enterprise admins groups. The schema admins
and enterprise admins groups are available only in the first domain in the
forest. If the messaging group does not control the forest root domain, this
process must be delegated to the group that does.

A schema change forces a full replication of domain databases and Global
catalog information in Active Directory. Many administrators are scared of full
replications and have heard stories of bandwidth-saturated WAN links due to
schema extensions. However, when a full replication occurs, the directory
information is compressed before it is sent across the network. The actual
amount of data sent across the wire will be approximately 15%–20% of the
actual Active Directory database size.

NOTE

For Windows NT 4.0 organizations still in the Active Directory planning
stages, to get an approximate size of the Active Directory database size
multiply the Windows NT 4.0 SAM database by a factor of 3. This is a good
ballpark estimate to use for the database size that will be seen immediately
after migration. To calculate the size after implementing Exchange 2003 and
other new directory information, use the AdSizer tool from Microsoft, available
at
http://www.microsoft.com/windowsserver2003/downloads/.

Preparing the Windows 2000 or Windows 2003 Domain

The second step in preparing to install Exchange 2003 is to prepare the
Windows 2000 or Windows 2003 domain that will host the Exchange servers or
mailbox-enabled users. To prepare the Windows 2000 or Windows 2003 domains, use
the /domainprep switch on setup.exe for Exchange 2003 or
follow the steps outlined in the deployment tool.

The account used to prepare the Windows 2000 or Windows 2003 domains must be
a member of the domain admins group in the domain where the /domainprep
command is being run. Running domainprep performs the following
operations on the domain:

Creates the global security group Exchange Domain Servers

Creates the domain local security group Enterprise Exchange
Servers

Adds the Exchange Domain Servers group to Enterprise Exchange Servers
group

Grants appropriate rights to the domain controller used for the Recipient
Update Service

For domains that will host mailbox-enabled users and not host Exchange
servers, administrators have the choice of running domainprep or
manually creating a Recipient Update Service for the domain in Exchange System
Manager. If the domain will never host Exchange servers, the Recipient Update
Service should be manually created. If the domain will eventually host Exchange
servers, domainprep should be used.