Exchange Server 2003 and Active Directory
Exchange 5.5 Server employed a dedicated directory that provided a central location for the organization’s objects, such as addresses, mailboxes, distribution lists, and public folders. This directory service also managed object replication among the Exchange 5.5 servers.
Exchange Server 2003 no longer uses a dedicated directory. Instead, it integrates with the Windows Server 2003 Active Directory service. Integration with Windows Server 2003 provides several benefits, including the following:
-
Centralized object management Administration is unified for Exchange Server 2003 and Windows Server 2003. Directory objects can be managed from one location, with one management tool, and by one team.
-
Simplified security management Exchange Server 2003 uses the security features of Windows Server 2003, such as the discretionary access control list (DACL). Changes to security principles (such as user or group accounts) apply to data stored in both Exchange 2003 and Windows Server 2003 file shares.
-
Simplified creation of distribution lists Exchange Server 2003 automatically uses Windows Server 2003 security groups as distribution lists, eliminating the need to create a security group for each department and a corresponding distribution group for the same department. Distribution groups can be created in those instances when e-mail distribution is the only desired function of the group.
-
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 2003 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 Server 2003 uses each of these partitions and which kind of data is stored in them.
Domain Naming Partition
In the domain naming partition, all domain objects for Exchange 2003 are stored and replicated to every domain controller in the domain. Recipient objects, including users, contacts, and groups, are stored in this partition.
Exchange Server 2003 exploits Active Directory by adding attributes to user, group and contact objects for messaging purposes. Because Exchange Server 2003 uses the same database as Windows Server 2003, some terminology has changed from Exchange 5.5 Server. Table 4-2 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.
| 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. |
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 2003 uses groups for this function. Any user accounts that are placed inside the group will receive the message. In Windows Server 2003 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 whenever a Universal Group’s 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.
Figure 4-5: Mail-enabling a group using 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.
Figure 4-6: Creating an SMTP alias in the Exchange Task Wizard.
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. If bandwith between the two domains is slow or unreliable, retrieving membership from a remote domain might take time and slow down message delivery, which will affect overall performance. It is best if Exchange Server 2003 is in the remote domain. Then you can set the expansion server to be the remote Exchange 2003 server instead of retrieving the membership remotely and expanding the group membership locally.
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. When you have multiple domains, use universal groups if the membership is fairly static (that is, global groups as opposed to individual users), and remember that users might 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 when membership changes frequently or 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.
Microsoft 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 Server 2003. 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)
Figure 4-8: Adjusting the SMTP recipient limit in the Exchange System snap-in. -
On the individual user’s account properties sheet in AD Users and Computers (Figure 4-9), where you can enter the value needed for that user. You access the Delivery Options screen by clicking the Delivery Options button on the Exchange General tab.
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. 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, “Understanding Exchange Server Routing Architecture.” |
Configuration Naming Partition
The configuration partition of Active Directory stores information regarding how your Exchange 2003 system is organized. Because this information is replicated to all domain controllers in the forest, the Exchange 2003 configuration is also replicated throughout the forest. The configuration information includes the Exchange 2003 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 Server 2003 in the forest, the Active Directory schema is extended to include new object classes and attributes that are specific to Exchange 2003. These new classes start with “ms Exch” and are derived from the LDAP Data Interchange Format (LDIF) files on the Exchange Server 2003 CD-ROM.
Given that these extensions represent more than 1000 changes to the schema and that these changes will be replicated to all the domain controllers in your forest, you should run ForestPrep for Exchange Server 2003 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 the schema changes into their own databases.
| Tip | You can install Exchange Server 2003 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. Also, generally, the earlier in an AD deployment that you extend schema, the better, because as domain controllers are added to the forest, they inherit the extended schema, thus reducing replication traffic when/forestprep is run. For more information on installing Exchange Server 2003, consult Chapter 7, “Installing Exchange Server 2003.” |
Generating E-Mail Addresses
Exchange Server 2003 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 e mail address are simplified, thus hiding the complexity of the underlying domain infrastructure.
Figure 4-10: Recipient policy properties.
| Note | In Figure 4-10, an X.400 address is associated with the user account. This X.400 address is required by Exchange Server 2003 and cannot be removed. Under the hood, Exchange is really an X.400-compliant message handling system. So is Novell’s GroupWise, IBM’s Lotus Notes, and other similar systems. Learning the X.400 standard will help you immensely in understanding the architecture of most e-mail systems that are in use today. You can purchase this standard from the folks at www.itu.org. |
Exchange Server 2003 and Forest Boundaries
Since Exchange Server 2003 stores much of its information in the configuration naming partition, an Exchange 2003 organization cannot be extended past the boundaries of the forest. This is one area in which your Active Directory structure will directly influence your Exchange topology. Having multiple forests in a company incurs the following limitations:
-
You have separate Exchange organizations to administer.
-
You have separate Global Address Lists, with no automatic directory replication between them.
-
You 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.
Cross-Forest authentication is available, however. See Chapter 25, “Securing Exchange Server 2003 Messages,” for a discussion about this topic.
If you want to synchronize directory information among multiple forests, you can use Microsoft MetaDirectory Services (MMS). 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 Servers
Exchange Server 2003 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 Windows Server 2003 site for scalability and redundancy. In a multidomain environment, be sure to place a Global Catalog server in each domain as well. Large installations can require more Global Catalog servers.
DSProxy
To determine how many Global Catalog servers you need for your site and domain structure, you need to understand how a Microsoft Outlook user and an Exchange Server 2003 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 Server 2003 uses the directory in Windows Server 2003, 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 Named Service Provider Interface (NSPI). Older Messaging Application Programming Interface (MAPI) clients, such as the older Exchange client or Microsoft 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 Server 2003, 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 Server 2003 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.
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\ |
The second function performed by DSProxy is to request that more recent versions of Outlook, such as Outlook 2000 or 2002, send all future directory calls directly to a specified Global Catalog server. Outlook 2002 clients first go through the DSProxy process for the initial directory lookup. DSProxy then passes back to the Outlook 2002 client a referral to send all future directory calls to a specified Global Catalog server, thus reducing the load on the Exchange Server 2003 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 2002 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.trainsbydave.com
If your clients need to access Active Directory through a firewall, you can open up the firewall to allow the Exchange Server 2003 to access Active Directory and turn off the DSProxy referral process to your Outlook 2000 clients. You can instruct the Exchange Server 2003 not to give out referrals in the following registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchange
SA\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 from SProxy 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).
You can also 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, the server is referring to itself for Active Directory services.
Figure 4-12: Property sheet for the Tucson server.
You’ll also notice that there is a check box to enable Exchange to Automatically Discover Servers. What this means is that Exchange will automatically discover the type of server selected in the Show list for the topology. When not selected, Exchange will use the server you manually specify using the Add and Remove buttons.
DSAccess
To reduce the number of calls to the Global Catalog server from your Exchange Server 2003, Exchange 2003 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 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 Server 2003.
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 Server 2003 as follows:
-
To adjust the expiration time for cached entries, use the following registry entry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
\MSExchange
DSAccess\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
\MSExchange
DSAccess\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
\MSExchange
DSAccess\Instance0
Value name: Max Entries
Value type: REG_DWORD
Value data: 0xXXXX (where XXXX = number of entries)
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 Server 2003 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 Server 2003.
When an Exchange Server 2003 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 Server 2003 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 Server 2003 servers and make sure that they are in the same site and domain.
 |
You can hard-code which servers Exchange Server 2003 contacts to obtain data. This task involves merely specifying a preference for your Exchange Server 2003. 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.trainsbydave.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: UserGC1Value type: REG_SZ
Value data: \\DirectoryServer.domain (for example, Tucson.hr.trainsbydave.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 Server 2003 eliminates ABVs and replaces them with address lists, which are created with build rules. These build 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 can 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 in 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 2003. Table 4-3 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.
| Address List | Build Rule |
|---|---|
| Default Global Address List | (&(|mail=*)(proxyAddress=*)(textEncodedORAddress=*)) |
| All users | (&(|mail=*)(proxyAddress=*)(textEncodedORAddress=*)) |
| All groups | (&(|mail=*)(proxyAddress=*)(textEncodedORAddress=*)) |
| All contacts | (&(|mail=*)(proxyAddress=*)(textEncodedORAddress=*)) |
| Public folders | (&(|mail=*)(proxyAddress=*)(textEncodedORAddress=*)) |
| All conference resources | M(msExchResourceGUID=*) |
Figure 4-15: Finding default address lists in the Exchange System snap-in.
EAN: 2147483647
Pages: 254