Exchange 2000 Server and Active Directory | Microsoft Exchange 2000 Server Adminstrator's Companion

[Previous] [Next]

Previous versions of Exchange employed a dedicated directory that provided a central location for the organization's objects, such as addresses, mailboxes, distribution lists, and public folders. A separate directory service was installed to manage object replication among the Exchange servers.

Exchange 2000 Server no longer uses a dedicated directory. Instead, it integrates with the Windows 2000 Active Directory service. Integration with Windows 2000 provides several benefits, including the following:

Centralized object management Administration is now unified for Exchange 2000 Server and Windows 2000 Server. Directory objects can be managed from one location, with one management tool, and by one team.

Simplified security management Exchange 2000 Server uses the security features of Windows 2000, such as the system access control list (SACL). Changes to security principles (such as user or group accounts) apply to data stored in both Exchange 2000 and Windows 2000 file shares.

Simplified creation of distribution lists Exchange 2000 Server automatically uses Windows 2000 security groups as distribution lists, eliminating the need to create a security group for each department and a corresponding distribution list for the same department.

Easier access to directory information LDAP is now the native access protocol for directory information. In earlier versions of Exchange, lookups in the directory were conducted over the Named Service Provider Interface (NSPI).

Storing Exchange 2000 Data in Active Directory

Earlier we mentioned that Active Directory is divided into three naming partitions: configuration, schema, and domain. In this section, we'll discuss how Exchange 2000 Server uses each of these partitions and which kind of data is stored in each.

Domain Naming Partition

In the domain naming partition, all of the domain objects for Exchange 2000 are stored and replicated to every domain controller in the domain. Recipient objects, including users, contacts, and groups, are stored in this partition.

Exchange 2000 Server exploits Active Directory by adding attributes to user and group objects for messaging purposes. Because Exchange 2000 Server uses the same database as Windows 2000, some terminology has changed from previous versions of Exchange Server. Table 4-3 lists directory objects in Exchange 5.5 Server and their Active Directory equivalents, and Figure 4-4 shows the dialog box used to mail-enable a user object.

Table 4-3. Comparison of Exchange 5.5 and Exchange 2000 directory terminology

Exchange 5.5 Directory Object	Equivalent Active Directory Object	Comments
Mailbox	Mailbox-enabled user	Mailbox-enabled users are security principles in Active Directory that can send and receive messages.
No direct correlation with a 5.5 object	Mail-enabled user	Mail-enabled users are those who can logon to your domain with a user account in your domain, but whose e-mail is sent to an external address. This type of user is best suited for long-term contractors who need access to resources on your network but who need to send and receive e-mail through their employer's e-mail system.
Custom recipient	Mail-enabled contact	All mail-enabled contacts have an SMTP address. These are always users outside your Exchange organization.
Distribution list	Mail-enabled group	Domain local, global, and universal groups can be mail enabled.
Public folder	Public folder	Mail-enabled public folders can be created only in the Exchange System snap-in or the Active Directory Connector.

click to view at full size.

Figure 4-4. Mail-enabling a user object.

Designing a Group Implementation Strategy Previous versions of Exchange use a distribution list to send the same message to a large number of recipients. Exchange 2000 uses groups for this function. Any user accounts that are placed inside the group will receive the message. In Windows 2000 native mode, groups can be nested inside of groups, effectively creating a multitiered distribution list. The two types of groups you will use most often for large distribution of a message are global and universal.

If you want to optimize the universal security groups that have been set up in Active Directory, you can mail-enable the groups (Figure 4-5) and then add an SMTP e-mail alias (Figure 4-6). Once completed, the group will be visible in the Global Address List (Figure 4-7). To mail-enable a group, right-click the group, choose Exchange Tasks, and then follow the prompts in the Exchange Task Wizard.

The largest downside to universal groups is that membership is fully replicated to each Global Catalog server, which means that replication traffic occurs when membership changes. Therefore, it is best to populate a universal group with other global groups, so that when membership changes in the global group, the universal group is not changed and traffic is not replicated.

click to view at full size.

Figure 4-5. Mail-enabling a group using the Exchange Task Wizard.

click to view at full size.

Figure 4-6. Creating an SMTP alias in the Exchange Task Wizard.

Global groups can also be mail-enabled for message distribution. If you choose not to use universal groups, you can mail-enable global groups. Membership for a global group is not promoted to the Global Catalog server, which presents some issues to consider when working in a multidomain environment.

click to view at full size.

Figure 4-7. Viewing the mail-enabled group in the Global Address List.

When a message is sent to a global group in a remote domain, the expansion server must connect to a domain controller in the group's home domain and retrieve the membership list. In addition, the expansion server must have IP connectivity to a domain controller in the group's home domain. Retrieving membership from a remote domain may take time and slow down message delivery, which will affect overall performance. It is best if there is an Exchange 2000 server in the remote domain. Then you can set the expansion server to that server instead of retrieving the membership remotely.

When deciding which group type to select, consider the following implications:

Whether you have a single-domain or multiple-domain environment If you have a single domain, you don't need to use universal groups, because all of the domain objects are local. If you have multiple domains, use universal groups if the membership is fairly static (global groups as opposed to individual users), and remember that users may not have access to all object attributes from other domains in universal groups.

Whether direct IP connectivity is possible between all domains If you have IP connectivity, use global groups if membership changes frequently or if you have Exchange servers in each domain that can act as expansion servers. Otherwise, use universal groups, since membership is static and the local expansion server can expand the list.

Whether membership changes frequently If membership changes often, use global groups. If membership changes infrequently, use universal groups.

Outlook users will not be able to view the user memberships of a group that has been created in a remote domain. They can view membership only in global groups and domain local groups that have been created in their home domain.

An Expansion server, which has been mentioned several times, requires some explanation. When a message is sent to a mail-enabled group, the message needs to be expanded and individually addressed to each member of the group. By default, the local SMTP server performs the expansion and uses LDAP to contact the Global Catalog server to deliver the message to each member of the group. If the message is intended for a local group in the domain, the local Global Catalog server is contacted.

By default, an SMTP message can be routed to only 100 recipients. This is a limitation of the SMTP protocol, not of Exchange 2000 Server. You can adjust this limit as required in one of three places:

On the Message Delivery object properties sheet under Global Settings, where the default for the entire organization is 5000 recipients per message

On the properties sheet for each SMTP virtual server in the Exchange System snap-in (Figure 4-8)

On the individual user's account properties sheet in AD Users and Computers (Figure 4-9), where you can input the value needed for that user.

Figure 4-8. Adjusting the SMTP recipient limit in the Exchange System snap-in.

Figure 4-9. Adjusting the SMTP recipient limit in AD Users and Computers.

NOTE
SMTP messages with more than 100 recipients are divided into multiple messages before being expanded, each with 100 recipients or less. And if the number of recipients exceeds the limit specified in the global SMTP settings, the message will not be processed. Limits are imposed by the transport core categorizer, which is discussed more fully in Chapter 3.

Configuration Naming Partition

The configuration partition of Active Directory stores information regarding how your Exchange 2000 system is organized. Because this information is replicated to all domain controllers in the forest, the Exchange 2000 configuration is also replicated throughout the forest. The configuration information includes the Exchange 2000 topology (such as routing group information), connectors, protocols, and service settings.

Schema Naming Partition

The schema partition contains all object types and their attributes that can be created in Active Directory. This information is replicated to all domain controllers in the forest. During the first installation of Exchange 2000 Server in the forest, the Active Directory schema is extended to include new object classes and attributes that are specific to Exchange 2000. These new classes start with "<d>msExch" and are derived from the LDAP Data Interchange Format (LDIF) files on the Exchange 2000 Server CD-ROM.

Given that these extensions represent more than 900 changes to the schema and that these changes will be replicated to all of the domain controllers in your forest, it's best to install Exchange 2000 Server at the beginning of a period of time when you anticipate that network activity will be relatively light—for instance, on a Friday night. This schedule will give the domain controllers time to replicate all of the schema changes into their own databases.

TIP
You can install Exchange 2000 Server using the /forestprep switch, which will write the new Exchange object classes and attributes to the schema but will not install Exchange itself. Plan on this activity taking anywhere from 30 to 90 minutes, depending on the speed and capacity of your hardware. For more information on installing Exchange 2000 Server, consult Chapter 7.

Generating E-Mail Addresses

Exchange 2000 Server gives you flexibility regarding how your e-mail addresses are generated. As Figure 4-10 shows, e-mail address generation is controlled by the recipient policies in the organization. The user's e-mail address will likely be different from the user's principal name. Since the e-mail address is just another attribute of the user object, you can set it up so that the user's logon name and email address are simplified, thus hiding the complexity of the underlying domain infrastructure.

Figure 4-10. Recipient policy properties.

Exchange 2000 Server and Forest Boundaries

Since Exchange 2000 Server stores much of its information in the configuration naming partition, an Exchange 2000 organization cannot be extended past the boundaries of the forest. This is one area where your Active Directory structure will directly influence your Exchange topology. Having multiple forests in a company incurs the following limitations:

You'll have separate Exchange organizations to administer.

You'll have separate Global Address Lists, with no automatic directory replication between them.

You'll need to use SMTP and/or X.400 Connectors to connect the multiple organizations.

No link state data will be transferred because Routing Group Connectors (RGCs) cannot be used.

If you want to synchronize directory information among multiple forests, you can use DirSynch Control. This utility provides the sharing of information between dissimilar directories in a mixed-directory environment, using LDAP calls to both directories. At the time of this writing, it has been submitted to the Internet Engineering Task Force (IETF) as an open standard. In the initial release of Windows 2000, there is no automatic way to synchronize two directories. If this is a requirement for your environment, you'll need to use third-party tools.

Public folders can be synchronized with the Public Folder Inter-organization Replication tool. This tool will also replicate Free/Busy system folders as well. Even with this functionality, users cannot open calendars across forest boundaries. In addition, bear in mind the additional administrative overhead of synchronizing public folders in this manner compared to performing this function in a single organization. If possible, the best practice is to create additional domains rather than forests to eliminate the need for multiple Exchange organizations in your company.

Integration with Global Catalog Server

Exchange 2000 Server needs regular access to the Global Catalog server for activities such as producing a Global Address List for mail-enabled users as well as for use by DSAccess and DSProxy. (These two Exchange services are discussed in the sections that follow.) Unless your network is small, with fewer than 20 light users, consider implementing at least two Global Catalog servers per site for scalability and redundancy. In a multidomain environment, be sure to place a Global Catalog server in each domain as well. Large installations may require more Global Catalog servers.

TIP
One test environment recently found that having more than 17 Exchange servers referencing the same Global Catalog server caused a significant decrease in performance, resulting in extended periods of unproductivity for the end users. You'll need to regularly monitor the Global Catalog server to discern the load being placed on it by the Exchange 2000 servers. If your company is growing, this will be a key area for you to manage. Microsoft doesn't give any hard and fast numbers or benchmarks to work with. The proper ratio of Exchange 2000 servers and Global Catalog servers is left to you to decide because each environment is different and unique.

DSProxy

When determining how many Global Catalog servers you need for your site and domain structure, you'll need to understand how a Microsoft Outlook user and an Exchange 2000 server access Active Directory. In Exchange 5.5, every server has a complete copy of the directory, which enables Outlook clients to refer to the directory on their home server. The Message Transfer Agent (MTA) uses the local directory to route messages. Now that Exchange 2000 Server uses the directory in Windows 2000, directory calls need to be referred to Active Directory.

DSProxy acts as a facilitator to allow Outlook clients to access the data within Active Directory. It performs two important functions. The first is to proxy directory requests on behalf of clients to Active Directory through the Name Service Provider Interface (NSPI). Older Messaging Application Programming Interface (MAPI) clients, such as the older Exchange client or Outlook 97/98, make MAPI Directory Service (MAPI DS) requests to an Exchange server over a remote procedure call (RPC) connection.

When an older MAPI client makes a directory request, the request is made to the Exchange 2000 server, as shown in Figure 4-11. The DSProxy NSPI then blindly forwards the MAPI DS directory call to a Global Catalog server. It does not open and evaluate the RPC packet, because doing so would incur too much system overhead for the Exchange 2000 server as well as complicating the security structure. It also does not change the request into an LDAP call over port 389. Active Directory can be accessed over a number of protocols, including LDAP and MAPI DS, so the forwarding of the packet has no effect on its ability to access Active Directory.

click to view at full size.

Figure 4-11. How older MAPI clients access the Global Catalog via DSProxy.

The Global Catalog server returns the results of the request to the Exchange 2000 DSProxy service, which in turn passes the results to the client. This entire process is transparent to the user.

TIP

If you need to specify the server that DSProxy uses manually, you can do so with the following registry entry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters
Value name: NSPI Target Server
Value Type: STRING
Value data: GC-Server-name
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters
Value name: RFR Target Server
Value type: STRING
Value data: GC-Server-name

The second function that DSProxy performs is to request that more recent versions of Outlook, such as Outlook 2000, send all future directory calls directly to a specified Global Catalog server. Outlook 2000 clients first go through the DSProxy process for the initial directory lookup. DSProxy then passes back to the Outlook 2000 client a referral to send all future directory calls to a specified Global Catalog server, thus reducing the load on the Exchange 2000 server and minimizing any possible latency issues for directory calls. If the Global Catalog server fails, the Outlook 2000 client will need to be restarted to obtain a new referral from DSProxy.

The Outlook 2000 client writes the referral in its registry under the following key:

HKEY_CURRENT_USER\Software\Microsoft\WindowsNT\CurrentVersion\Windows MessagingSubsystem\Profiles\profilename\cda7392…..2fe19873

Value name: 001e6602

Value type: STRING

Value data: \\Directoryserver.domain

Example: \\indianapolis.hr.oaktree.com

If your clients need to access Active Directory through a firewall, you can open up the firewall to allow the Exchange 2000 server to access Active Directory and turn off the DSProxy referral process to your Outlook 2000 clients. You can instruct the Exchange 2000 server not to give out referrals in the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters

Value name: No RFR Service

Value type: DWORD

Value data: 0x1

If the Global Catalog server being used by DSProxy fails, DSProxy issues a callback to the System Attendant service (Mad.exe), which, in turn, issues to DSProxy a new server name to use. This process is known as retargeting. The System Attendant will not retarget unless it receives a request for DSProxy to do so. When the Exchange System Attendant service starts, it finds the most appropriate Active Directory server by referencing DNS, and then it passes the server's name to the DSProxy process (Dsproxy.dll).

It is also possible to determine which Active Directory domain controller a given Exchange server is using by viewing the properties of the Exchange computer in the Exchange System snap-in. In Figure 4-12, since Tucson is both an Exchange server and a domain controller, it is referring to itself for Active Directory services.

Figure 4-12. Property sheet for the Tucson server.

DSAccess

To reduce the number of calls to the Global Catalog server from your Exchange 2000 server, Exchange 2000 implements a directory access cache (DSAccess). This cache holds recent directory lookup information so that if the same information is requested within a specified period of time, the results can be returned to the client from the cache.

Increasing the cache size or the cache time will decrease the number of calls DSProxy and Outlook 2000 clients make to a Global Catalog server. You'll want to first measure the stress on the Global Catalog server and then, if necessary, modify the registry on the Exchange 2000 server.

The default parameters for cache size and cache time are a maximum of 4 MB of directory entries, which can be cached for up to 10 minutes. You can change these parameters in the registry of the Exchange 2000 server as follows:

To adjust the expiration time for cached entries, use the following registry entry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Instance0

Value Name: CacheTTL

Value Type: Reg_WORD

Value data: 0xXXXX (where XXXX = number of seconds desired)

To adjust the size of the cache itself, use the following registry entry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ MSExchangeDSAccess\Instance0

Value name: MaxMemory

Value Type: Reg_DWORD

Value data: 0xXXXX (where XXXX = number of kilobytes desired)

You can also specify the maximum number of entries in the cache, rather than its overall size, as follows:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ MSExchangeDSAccess\Instance0

Value name: Max Entries

Value type: REG_DWORD

Value data: 0xXXXX (where XXXX = number of entries)

NOTE
Each cached entry requires about 3.6 KB of memory, and the overhead to run DSAccess is approximately 2.5 MB.

Configuration Partition and Directory Data

The two Active Directory services that an Exchange 2000 server uses most often are the Global Catalog server for address book lookups and the configuration naming partition for routing information. It is possible that two different domain controllers will be referenced, depending on the type of request being made by the Exchange 2000 server.

When an Exchange 2000 server boots up, it establishes a number of LDAP connections to domain controllers and Global Catalog servers. If it needs routing information to route a message, it can contact any domain controller to obtain this information, because each domain controller in the forest has a full copy of the configuration naming partition. If the Exchange 2000 server needs to obtain the Global Address List, it will contact the closest Global Catalog server. Best practice is to place a Global Catalog server near the Exchange 2000 servers and make sure that they are in the same site and domain.

Manually Configuring Exchange 2000 Servers for Global Catalog Lookups

You can hard-code which servers Exchange 2000 Server contacts to obtain data. This task involves merely specifying a preference for your Exchange 2000 server. Should the specified server be offline, Exchange fails over to standard DNS lookups.

To specify the domain controller to contact for configuration partition information, use the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Instance0
Value Name: ConfigDCHostName
Value type: REG_SZ
Value data: \\DirectoryServer.domain (for example, Tucson.hr.oaktree.com)

Value name: ConfigDCPortNumber
Value type: REG_DWORD
Value data: 0x389 (the default LDAP port number is 389)

To specify the domain controller to contact for address book lookups, use this registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Profiles\Default
Value Name: UserGC1
Value type: REG_SZ
Value data: \\DirectoryServer.domain (for example, Tucson.hr.oaktree.com)

Value name: PortNumber
Value type: REG_DWORD
Value data: 0x3268 (the default port number for a GC server)

Value name: IsGC
Value type: REG_DWORD
Value data: 0x1 (always set to 1 if the server specified is a GC server)

Address Book Views

In Exchange 5.5, the view consistency checker (VCC) service runs in the background every 5 minutes, creating a new address book view (ABV) for each unique string of characters in the field that is being sorted. This method is not flexible for larger organizations and creates unwanted ABVs when words are misspelled or entered incorrectly.

Exchange 2000 Server eliminates ABVs and replaces them with address lists, which are created with build rules. These rules use the LDAP search filter syntax defined in RFC 2254 and are extremely flexible. In fact, as Figure 4-13 shows, the Global Address List is built using a filter rule.

Figure 4-13. Property sheet for the Global Address List, showing the filter rule.

TIP
When you click the Preview button shown in Figure 4-13, you'll get to test your build rule by having it used to search through the directory and find matching objects. If you get a list that isn't what you expected, you can modify your build rule. By testing your build rule here, you are not forced to close and open the address book properties multiple times to see the effects of a newly written rule.

Address lists are updated when the System Attendant service (Mad.exe) makes a call to Wldap32.dll. You can specify the frequency of this action on the property sheet for the Recipient Update service (Figure 4-14). To perform an update, the System Attendant service contacts a local domain controller, searches Active Directory for the objects and attributes specified in the build rule, and creates the new address list.

Figure 4-14. Property sheet for the Recipient Update service.

Several default address lists are configured in Exchange 2000.Table 4-4 lists the build rules for each of these default lists. Figure 4-15 shows where you can find the default lists in the Exchange System snap-in.

Table 4-4. Build rules for default address lists in Exchange 2000

Address List	Build Rule
Default Global Address List	(&(\|mail=)(proxyAddress=)(textEncodedORAddress=*)) (\|(objectCategory=person)(objectCategory=group) (objectCategory=publicFolder)))
All users	(&(\|mail=)(proxyAddress=)(textEncodedORAddress=*)) (\|(objectCategory=person)(objectClass=user))))
All groups	(&(\|mail=)(proxyAddress=)(textEncodedORAddress=*)) (\|(objectCategory=group)))
All contacts	(&(\|mail=)(proxyAddress=)(textEncodedORAddress=*)) (\|(objectCategory=person)(objectClass=contact))
Public folders	(&(\|mail=)(proxyAddress=)(textEncodedORAddress=*)) (\|(objectCategory=publicFolder)))
All conference resources	M(msExchResourceGUID=*)

click to view at full size.

Figure 4-15. Finding default address lists in the Exchange System snap-in.