Understanding Network Services and Active Directory Domain Controller Placement for Exchange Server 2013 (part 11)

Understanding AD Functionality Modes and Their Relationship to Exchange Groups

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 Server 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 2013, specifically Active Directory group functionality. Consequently, a firm grasp of these concepts is warranted.

Understanding Windows Group Types

Groups in Windows Server 2012 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 Server.

Defining Distribution Groups

The concept of distribution groups as it exists in Windows Server 2012 was first introduced in Windows 2000 Server 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 2012.

Outlining Mail-Enabled Security Groups in Exchange Server 2013

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 Server 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, 2003, 2008, or 2012 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 2012, however, because the membership of each group is incrementally replicated.

Universal groups are particularly important for Exchange environments. For example, when migrating from Exchange Server 5.5 to later versions of Exchange, the Exchange Server 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 Server 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.

Mail-enabled groups should be universal groups for full Exchange function, especially in multiple-domain forests.

Functional Levels in Windows Server 2012 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 Windows Server 2012, and five separate functional levels exist at the forest level:

• Windows 2000 Server Native—Installed into a Windows 2000 Server Active Directory that is running in Windows 2000 Server Native mode, Windows Server 2003 runs itself at a Windows Server 2000/2003 functional level. Only Windows 2000 Server and Windows Server 2003 domain controllers can exist in this environment.

• Windows Server 2003—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, Windows Server 2008, or Windows Server 2012. Only after this can the domains, and then the forest, be updated to Windows Server 2003 functionality.

• Windows Server 2008—Windows Server 2012 functionality is the eventual goal of all Windows Server 2008 Active Directory implementations. Functionality on this level opens the environment to features such as Distributed File System (DFS) replication of SYSVOL, Advanced Encryption Standard (AES) support for Kerberos, last interactive logon information, and finer-grained password policies. To get to this level, first all domain controllers must be updated to Windows Server 2008 or higher. Only after this can the domains, and then the forest, be updated to Windows Server 2008 functionality.

• Windows Server 2008 R2—Functionality at this level adds authentication mechanism assurance, which supports advanced identity management. Only Windows Server 2008 R2 or Windows Server 2012 domain controllers are supported.

• Windows Server 2012—No additional features are added at this level, but only Windows Server 2012 domain controllers are supported. This serves to ensure that older domain controllers are not joined to the forest.

As previously mentioned, it is preferable to convert AD domains into at least Windows 2000 Server Native mode or Windows Server 2003 Functional mode before migrating Exchange Server 5.5 servers that use those domains. The universal group capabilities that these modes provide for make this necessary. And if possible, upgrade all domain controllers to Windows Server 2012 and raise the functional level to Windows Server 2012 Functional mode.

To change domain and forest functional levels in Active Directory to the highest level for Windows Server 2012, follow these steps:

1. Open Active Directory Domains and Trusts tool.

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 2012, 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 2012, as shown in Figure 10.

Figure 10. Windows Server 2012 forest functional level.