The most recent versions of Exchange Server,
as well as Active Directory, were designed to break through the
constraints that had limited previous Exchange implementations. However,
realistically, it was understood that the products would have to
maintain a certain level of compatibility with previous NT domains and
Exchange 5.5 organizations. After all, not all companies have the
resources to completely replace their entire network and messaging
infrastructure at once. This requirement stipulated the creation of
several functional modes for AD and Exchange that allow backward
compatibility, while necessarily limiting some of the enhanced
functionality—at least for the duration of the migration/upgrade
process. Several of the limitations of the AD functional modes in
particular impact Exchange Server 2007, specifically Active Directory
group functionality. Consequently, a firm grasp of these concepts is
warranted.
Understanding Windows Group Types
Groups in Windows Server 2003 come in two
flavors: security and distribution. In addition, groups can be organized
into different scopes: machine local, domain local, global, and
universal. It might seem complex, but the concept, once defined, is
simple.
Defining Security Groups
The type of group that most administrators are
most familiar with is the security group. A security group is primarily
used to apply permissions to resources, enabling multiple users to be
administered more easily. For example, users in the Sales department can
be added as members to the Sales Department security group, which would
then be given permission to specific resources in the environment. When
a new member is added to the Sales department, instead of modifying
every resource that the department relies on, you can simply
add the new member to the security group and the appropriate
permissions would be inherited by the new user. This concept should be
familiar to anyone who has administered down-level Windows networks,
such as NT or Windows 2000.
Defining Distribution Groups
The concept of distribution groups as it exists
in Windows Server 2003 was first introduced in Windows 2000 with the
deployment of Active Directory. Essentially, a distribution group is a
group whose members are able to receive mail messages that are sent to
the group. Any application that has the capability of using Active
Directory for address book lookups can use this functionality in Windows
Server 2003.
Note
Distribution groups can be used to create email
distribution lists that cannot be used to apply security. However, if
separation of security and email functionality is not required, you can
make security groups mail-enabled instead of using distribution groups.
Outlining Mail-Enabled Security Groups in Exchange Server 2007
With the introduction of Exchange into an Active
Directory environment came a new concept: mail-enabled groups. These
groups are essentially security groups that are referenced by an email
address, and can be used to send SMTP messages to the members of the
group. This type of functionality becomes possible only with the
inclusion of Exchange 2000 or greater, and Exchange actually extends the
forest schema to enable Exchange-related information, such as SMTP
addresses, to be associated with each group.
Most organizations will find that the use of
mail-enabled security groups will satisfy the majority of their group
requirements. For example, a single group called Marketing, which
contains all users in that department, could also be mail-enabled to
allow users in Exchange to send emails to everyone in the department.
Explaining Group Scope
Groups in Active Directory work the way that
previous group structures, particularly in Windows NT, have worked, but
with a few modifications to their design. As mentioned earlier, group
scope in Active Directory is divided into several groups:
Machine local groups—
Machine local groups, also known as local groups, previously existed in
Windows NT 4.0 and can theoretically contain members from any trusted
location. Users and groups in the local domain, as well as in other
trusted domains and forests can be included in this type of group.
However, local groups allow resources only on the machine they are
located on to be accessed, which greatly reduces their usability.
Domain local groups—
Domain local groups are essentially the same as local groups in Windows
NT, and are used to administer resources located only on their own domain.
They can contain users and groups from any other trusted domain and are
typically used to grant access to resources for groups in different
domains.
Global groups—
Global groups are on the opposite side of domain local groups. They can
contain only users in the domain in which they exist, but are used to
grant access to resources in other trusted domains. These types of
groups are best used to supply security membership to user accounts who
share a similar function, such as the sales global group.
Universal groups—
Universal groups can contain users and groups from any domain in the
forest, and can grant access to any resource in the forest. With this
added power comes a few caveats: First, universal groups are available
only in Windows 2000 or 2003 AD Native mode domains. Second, all members
of each universal group are stored in the global catalog, increasing
the replication load. Universal group membership replication has been
noticeably streamlined and optimized in Windows Server 2003, however,
because the membership of each group is incrementally replicated.
Universal groups are particularly important for
Exchange environments. For example, when migrating from Exchange 5.5 to
later versions of Exchange, the Exchange 5.5 distribution lists were
converted into universal groups for the proper application of public
folder and calendaring permissions. An AD domain that contains accounts
that have security access to Exchange 5.5 mailboxes must be in AD Native
mode before performing the migration. This is because the universal
groups are made as Universal Security groups, which are only available
in AD Native mode.
Functional Levels in Windows Server 2003 Active Directory
Active Directory was designed to be
backward-compatible. This helps to maintain backward compatibility with
Windows NT domain controllers. Four separate functional levels exist at
the domain level in Windows Server 2003, and three separate functional
levels exist at the forest level:
Windows 2000 Mixed—
When Windows Server 2003 is installed in a Windows 2000 Active
Directory forest that is running in Mixed mode, Windows Server 2003
domain controllers will be able to communicate with Windows NT and
Windows 2000 domain controllers throughout the forest. This is the most
limiting of the functional levels, however, because certain
functionality—such as universal groups, group nesting, and enhanced
security—is absent from the domain. This is typically a temporary level
to run in because it is seen more as a path toward eventual upgrade.
Windows 2000 Native—
Installed into a Windows 2000 Active Directory that is running in
Windows 2000 Native mode, Windows Server 2003 runs itself at a Windows
2000/2003 functional level. Only Windows 2000 and Windows Server 2003
domain controllers can exist in this environment.
Windows Server 2003 Interim—
Windows Server 2003 Interim mode gives Active Directory the capability
of interoperating with a domain composed of Windows NT 4.0 domain
controllers only. Although a confusing concept at first, the Windows
Server 2003 interim functional level does serve a purpose. In
environments that seek to upgrade directly from NT 4.0 to Windows Server
2003 Active Directory, Interim mode enables Windows Server 2003 to
manage large groups more efficiently than if an existing Windows 2000
Active Directory exists. After all NT domain controllers have been
removed or upgraded, the functional levels can be raised.
Windows Server 2003—
The most functional of all the various levels, Windows Server 2003
functionality is the eventual goal of all Windows Server 2003 Active
Directory implementations. Functionality on this level opens the
environment to features such as schema deactivation, domain rename,
domain controller rename, and cross-forest trusts. To get to this level,
first all domain controllers must be updated to Windows Server 2003.
Only after this can the domains, and then the forest, be updated to
Windows Server 2003 functionality.
Note
Beginning with Exchange Server 2003 Service
Pack 1, Microsoft extended the ability to perform domain rename on an
Active Directory forest that was previously extended for Exchange.
Before SP1, it was not possible to rename an AD domain within a forest
that contained Exchange.
As previously mentioned, it is preferable to
convert AD domains into Windows 2000 Native mode, or Windows Server 2003
Functional mode before migrating Exchange 5.5 servers that use those
domains. The universal group capabilities that these modes provide for
make this necessary.
To change domain and forest functional levels in
Active Directory to the highest level for Windows Server 2003, follow
these steps:
1. | Open Active Directory Domains and Trusts from Administrative Tools.
|
2. | In the left scope pane, right-click your domain name, and select Raise Domain Functional Level.
|
3. | Click on the Available Domain Functional Level option, select Windows Server 2003, and then choose Raise.
|
4. | At the warning screen, click OK, and then click OK again to complete the task.
|
5. | Repeat the steps for all domains in the forest.
|
6. | Perform the same steps on the forest root, except this time click Raise Forest Functional Level, and follow the prompts.
|
After the domains and the forest have been upgraded, the Functional mode will indicate Windows Server 2003, as shown in Figure 1.