Are you administering a messaging environment already? Then you are most likely forced to accomplish the same or similar steps multiple times using dissimilar utilities. For example, in a Windows NT/Exchange Server 5.5 environment, you need to maintain user accounts in a Windows NT domain and associated mailboxes in an Exchange Server directory. The integration of Exchange 2000 Server with Active Directory overcomes the duplication of similar information in multiple directory repositories and will help reduce your system maintenance overhead. With Exchange 2000 Server, the quality of your messaging administration depends on the quality of the Active Directory design.
This lesson covers in more detail how Exchange 2000 Server uses Active Directory. You are introduced to directory extensions for Exchange 2000 Server and various aspects important to successfully maintaining your Exchange 2000 organization.
At the end of this lesson, you will be able to:
Estimated time to complete this lesson: 2 hours
When designing your Active Directory hierarchy, you typically need to reflect the physical and logical structure of your resources. The physical structure is based on sites, and the logical structure is comprised of the individual directory objects, organizational units (OUs), domains, trees, and forests.
Sites are combinations of IP subnets connected to each other via high-speed network links. They are used to optimize the directory replication (see "Active Directory Replication" later in this lesson). A Windows 2000 domain, on the other hand, is the core unit of the logical structure. Domains contain OUs and are arranged in a tree and a forest. OUs can contain other OUs as well as directory objects. Every individual directory object, maintained in an OU, represents a distinct set of attributes (display name, e-mail address, title, etc.) for a network resource, such as a user account, workstation, server, printer, shares, files, and so on. For detailed information about Active Directory see the Microsoft Windows 2000 Server Resource Kit, especially the Windows 2000 Server Distributed Systems Guide.
Using the Active Directory Users and Computers Snap-In, you can create additional OUs in a domain. It is easy to move directory objects between OUs. Just right-click the desired directory object, such as Administrator, and then, from the shortcut menu, select Move. In the Move dialog box, select the desired target OU, and then click OK to move the account into the specified OU. This can provide a high level of convenience, for instance, if a user moves between departments in an environment where departments are mapped to OUs in the Active Directory architecture. Instead of deleting and re-creating the user account and mailbox, move the corresponding directory object to its new location and the job is done. If you have administered a previous version of Exchange Server, you will especially appreciate this convenience. You can read more about the management of directory objects and the configuration of security settings and group policies in Chapter 13, "Creating and Managing Recipients."
Less complex environments will find a single domain environment sufficient. Windows 2000 domains include one or more domain controllers and define the security boundary for all network resources they contain. Domain controllers authenticate users and hold a complete replica of their own domain information as well as configuration and schema information from other domains that may exist in the same forest. In complex environments with numerous users, domains are used to physically organize domain account objects (such as user, group, computer, and printer accounts).
Use the DCPROMO.EXE utility to promote a computer running Windows 2000 Server to a domain controller. The same utility can also be used to demote domain controllers. Access control lists (ACLs) define the permissions associated with directory objects. ACLs control user or group access to particular objects, as outlined in more detail in Chapter 19, "Implementing Advanced Security."
NOTE
Plan your domain environment carefully and keep in mind that Active Directory domains cannot be renamed. This functionality may be available in future versions of Windows 2000.
Complex environments might require a more involved domain architecture, such as the one shown in Figure 2.3, especially if very granular network management is desired. You can arrange multiple domains in a hierarchical manner to establish a parent-child relationship between these domains. An arrangement of parent and child domains is known as a domain tree.
Figure 2.3 shows an arrangement of multiple domain trees. This structure is called a forest. It is worth noting that a particular Active Directory database can only hold the configuration and schema information from a single forest. This information is replicated to all domain controllers in every domain of the forest.
NOTE
It is advisable to deploy a single Active Directory forest to enable a common security model and to be able to replicate configuration and schema information across your organization. A single Exchange 2000 organization cannot span multiple forests, but it is possible to spawn multiple domains of a single forest.
Figure 2.3 Multiple domain trees in a forest
Every DNS name of a child domain in the hierarchy contains the name of the parent domain. For instance, the subdomain CA.BlueSky-inc-10.com contains BlueSky-inc-10.com (see Figure 2.3), which is exactly the name of the first domain in the forest. Both domains form a domain tree and, because the child object contains the name of the parent object, they also form a continuous namespace.
The domain BlueSky-inc-10.fr, on the other hand, does not form a continuous namespace with BlueSky-inc-10.com because BlueSky-inc-10.com is not included in BlueSky-inc-10.fr. Consequently, both domains are not part of the same tree, yet they are still interrelated because they are part of the same forest and share configuration and schema information. Objects that do not share a common naming structure but are interrelated (such as multiple trees in a forest) form a disjointed namespace.
In this exercise you will create a continuous namespace spanning two domains by adding a child domain to BlueSky-Inc-10.com. Completing the following procedure is a prerequisite for other exercises in subsequent sections and chapters.
To view a multimedia demonstration that displays how to perform this procedure, run the EX2CH2*.AVI files from the \Exercise_Information\Chapter2 folder on the Supplemental Course Materials CD.
To create a single domain tree of two domains
User Name | Administrator |
Password | password |
Domain | BlueSky-inc-10 |
At this point, you should be able to verify that BLUESKY-SRV2 is a host in the child domain CA.BlueSky-inc-10.com, which contains the parent tree BlueSky-inc-10.com in its domain name (see Figure 2.4).
Figure 2.4 A child domain's DNS name
It is relatively easy to create multiple domains in a domain tree, provided DNS is configured properly and you have the required permissions. Start the DCPROMO.EXE utility (which resides in the \Winnt\System32 directory) and make sure you choose the Create A New Child Domain In An Existing Domain Tree option. At this point, you need to specify the parent domain. You may specify the first domain installed in the forest or another subdomain that already exists. It is not possible, however, to use DCPROMO.EXE for creation of parent domains (domains above the first domain or above a sublevel domain). You may, however, use DCPROMO.EXE to remove a sublevel domain from the domain tree by demoting the domain controller(s) to member server(s).
Active Directory includes a replication feature that ensures that changes to a domain controller, including changes made to your Exchange 2000 organization, are passed along to all other domain controllers in the same domain. Replication can be performed via IP, synchronous remote procedure call (RPC) communication, or via Simple Mail Transfer Protocol (SMTP; e-mail messages). IP-based and synchronous RPC communication works best over fast and reliable network connections (such as a local area network [LAN]). SMTP-based communication via e-mail, on the other hand, is an alternative if network connections are unreliable, slow, or if data transfer generates costs (such as a wide area network [WAN]). The physical structure of your Active Directory environment determines the communication mechanism used for replication.
Only replication links between sites need to be configured manually. Sites can contain computers from a single domain and from multiple domains (see Figure 2.5). Multiple Windows 2000 sites may also exist within a single domain. The configuration of sites and site links is covered in detail in the Windows 2000 Server Distributed Systems Guide of the Microsoft Windows 2000 Server Resource Kit.
Figure 2.5 Active Directory sites and directory replication
NOTE
Windows 2000 sites are only used to identify regions in the network where fast and reliable connections are present. They do not serve any purpose for Exchange 2000 administration. Here, you will use administrative and routing groups instead, which are covered in Chapter 4, "Planning the Microsoft Exchange 2000 Server Installation."
When you install Exchange 2000 Server, the setup routine automatically extends the Active Directory forest. To demonstrate this, log on to your test computer BLUESKY-SRV1 (where Exchange 2000 Server is installed), start the Active Domain Users And Computers utility, and display the properties of the Administrator object. You will discover Exchange 2000-related property pages, such as Exchange General, which provides you with information about the Mailbox Store and the Alias name and gives you the option to set Delivery Restrictions, Delivery Options, and Storage Limits. This information did not exist before the installation of Exchange 2000 because it isn't relevant to standard Windows 2000 administration.
During the installation of the very first Exchange 2000 server in an organization, the Setup program will take an extended period of time to extend the forestwide Active Directory schema (see Figure 2.6). You may have noticed this when installing Exchange 2000 on BLUESKY-SRV1 in your test environment. Schema extensions are required to provide you with the ability to manage Exchange 2000 resources.
The schema consists of numerous classes that represent the various instances of directory objects (user, computer, connector, etc.) and specifies the relationships between classes. Classes are sets of object attributes (user name, logon name, alias, etc.), and attributes are governed by syntaxes (single value, multiple value, data type, etc.). Exchange 2000 adds new classes to the schema as well as new attributes to existing object classes. Likewise, existing attributes are modified to replicate them to the Global Catalog. You can find detailed information about the Active Directory schema in the Windows 2000 Server Distributed Systems Guide of the Windows 2000 Server Resource Kit, specifically in Chapter 4, "Active Directory Schema."
Figure 2.6 Extending the Active Directory schema
In this exercise you will examine the Active Directory schema extensions for Exchange 2000. For this purpose, you need to install a specific Windows 2000 snap-in called Active Directory Schema, which allows you to display the individual object classes and attributes.
To view a multimedia demonstration that displays how to perform this procedure, run the EX3CH2.AVI files from the \Exercise_Information\Chapter2 folder on the Supplemental Course Materials CD.
To verify the presence of Exchange 2000 schema extensions
At this point, scroll down to the class named msExchPFTree, as shown in Figure 2.7. Double-click on this object to display its properties. Switch to the Attributes property page and check the list of optional attributes that form this class, then click OK to close the dialog box.
Figure 2.7 Exchange 2000 object classes and attributes
Descriptions of Exchange 2000-specific attributes begin with msExch. They are added to Active Directory as part of the first Exchange 2000 installation and are replicated to all domain controllers in the forest. Permissions of a schema admin (member of the Windows 2000 group Schema Admins) are required to change the configuration. Should those permissions be missing, settings are displayed in read-only mode. Attribute settings may be changed manually or automatically (for instance, through the Exchange 2000 Setup program) to include, for example, specific attributes for Global Catalog replication, address name resolution, and address book searches.
When you use Outlook to connect to your server-based mailbox and open the address book to look up recipient information from your Exchange 2000 organization, this information does not come from your Exchange 2000 server at all; instead it is retrieved from the Windows 2000 Global Catalog server. However, Outlook and other previous MAPI-based clients, such as the legacy Exchange Client, are typically not aware of the Global Catalog and expect to communicate with an Exchange directory service. Earlier versions of Exchange Server provided their own directory service.
To support MAPI-based clients, Exchange 2000 Server provides a feature known as DSProxy. DSProxy forwards directory lookups of MAPI-based clients straight to a Global Catalog server. MAPI-based clients obtain access to Active Directory by using the Name Service Provider Interface (NSPI). DSProxy also keeps a reference of connections between clients and servers, ensuring that the response from the Global Catalog is passed to the correct client (see Figure 2.8).
Figure 2.8 Directory lookups via DSProxy and Global Catalog
NOTE
DSProxy requires TCP/IP, Internetwork Packet Exchange (IPX), or the AppleTalk protocol. NetBEUI is not supported.
The DSProxy process is part of the Microsoft Exchange System Attendant service, and is implemented in DSPROXY.DLL, which resides in the \Program Files\Exchsrvr\bin folder. You can verify its activities in the Windows 2000 Event Log, although you probably do not yet have any such event logged. Start the Event Viewer from the Administrative Tools program folder and filter the details of the Application Log; under Event Source select MSExchangeSA and under Category select NSPI Proxy (this stands for Name Service Provider Interface). You can read more about the System Attendant and other important Exchange 2000 services in Chapter 3, "Microsoft Exchange 2000 Server Architecture."
Global Catalog servers are specific domain controllers that support forestwide directory lookups. By default, only the first domain controller in the forest is a Global Catalog server, but you can add one or more to increase the fault tolerance. When you start Exchange 2000 Server, the System Attendant service detects the Global Catalog servers to be used by DSProxy. You also have the ability to statically reference a Global Catalog by adjusting the parameters of the System Attendant in the Registry. Add the value NSPI Target Server (type REG_SZ) under
HKEY_LOCAL_MACHINE \System\ \CurrentControlSet \Services \MSExchangeSA \Parameters
and set it to the name of the desired Global Catalog server.
NOTE
Setting the NSPI Target Server manually via the NSPI Target Server Registry parameter may be necessary in some situations; however, this decreases system resilience. The Registry setting overrides the list of automatically detected catalog servers. If the Global Catalog specified is not available for any reason, MAPI-based clients cannot log on to their mailboxes.
DXProxy, especially its Director Service Referral (RFR) Interface, also has the ability to divert so-called smart MAPI clients (such as Outlook 2000) to the Global Catalog directly. Windows 2000 domain controllers support MAPI as well as Lightweight Directory Access Protocol (LDAP), and can therefore communicate with Outlook 2000 without proxying. Outlook 2000 only needs to learn that it should contact a Global Catalog. To cause DSProxy to divert Outlook 2000 and other smart clients, set the registry parameter RFR Target Server (type REG_SZ) on the server to the name of the desired Global Catalog server under
HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \MSExchangeSA \Parameters
Outlook 2000 stores the Global Catalog server name received from DSProxy in its MAPI profile and uses it for all subsequent directory access. Consequently, diverting Outlook 2000 to the Global Catalog can reduce the load on the Exchange 2000 server and the latency for address book lookups. You can read more about MAPI and the configuration of MAPI profiles in Chapter 9, "MAPI-Based Clients."
Global Catalog servers must be registered through service (SRV) records in DNS. If your DNS server supports dynamic updates, Windows 2000 registers the required information automatically. In the test environment, use the DNS snap-in to find the corresponding _gc records, for instance, under DNS\BLUESKY-SRV1\Forward Lookup Zones\Bluesky-inc-10.com\_msdcs\gc\_tcp. The name of the record will be _ldap.
MAPI-based clients communicate with the Exchange directory service in many situations, such as for client logon, displaying the address book, resolving recipient information, and so forth. Consequently, the Global Catalog is heavily utilized in an Exchange 2000 environment and can become bottlenecked. Configure multiple Global Catalog servers if possible. This is accomplished quickly using the Active Directory Sites and Services snap-in. In the console tree, open Sites, then Default-First-Site-Name, then Servers, and then the desired server, such as BLUESKY-SRV2. Right-click NTDS Settings, and then select Properties. In the General property page, select the Global Catalog check box, and then click OK.
Exchange 2000 Server can balance the generated workload between the available Global Catalog servers. For scalability and resilience, at least two Global Catalog servers should exist per Active Directory site; if your site spans multiple domains, configure at least one Global Catalog in each domain.