Managing the Exchange Organization Topology

Windows IT Pro

- Advertise

Managing the Exchange Organization Topology
View the book table of contents

Author:	Mike Daugherty
Published:	June 2000
Copyright:	2001
Publisher:	Digital Press

Sites
Windows 2000 sites are based on physical network topology. A site is a collection of Windows 2000 servers that can communicate over a highly reliable, high bandwidth, permanent connection. Typically, this translates to a range of IP subnets, or a collection of subnet ranges that have local area network (LAN) speeds.

There is no direct relationship between Windows 2000 sites and domains. A domain is a logical concept, and a site is a physical concept. Multiple sites can exist within a single domain, and a single site can include multiple domains. A site has boundaries based on the physical network topology, not on the logical domain topology.

Because communication between computers in the same site is reliable, fast, and efficient, you can use site definitions to take advantage of the physical network. There are two primary ways that sites enable you to optimize network traffic across the WAN:

Replication. Replication of directory information between domain controllers within the same site is done using Remote Procedure Calls (RPCs). These RPCs are not scheduled, and the information is not compressed. Replication between domain controllers in different sites is done using SMTP. These replication messages can be scheduled and the data is compressed. Uncompressed RPCs generate quite a bit of network traffic, and if your domain includes domain controllers connected over a WAN, this can be quite slow. You can use site definitions to specify where RPC-based replication is used.
Logon authentication. Windows 2000 sites assist users in finding the closest domain controller to validate logon credentials. When a user requires logon authentication, the user’s workstation sends a request to the DNS server to locate domain controllers within the workstation’s site. The DNS server attempts to match the workstation’s IP address to a matching subnet defined in a site. If a match is found, the DNS server returns the names of the local domain controllers that can authenticate the logon. The client workstation will pick a domain controller and will attempt to ping the DC before logging on. If the domain controller fails to respond, the client workstation attempts to use another domain controller.

You define sites and build site links to describe the network using the Active Directory Sites and Services MMC console. The Knowledge Consistency Checker (KCC) then automatically creates connections to establish an efficient, reliable replication topology.

The terminology chosen by Microsoft is unfortunate since previous versions of Exchange Server had used the term site to describe a logical grouping of servers. With Exchange 2000, the concept of an Exchange site has been replaced by administrative groups and routing groups, but some confusion is likely to remain.

Although the Windows 2000 site concept has been inherited from previous versions of Exchange Server, there are some important conceptual differences as described in Table 4.

TABLE 4: WINDOWS 2000 SITES AND EXCHANGE 5.5 SITES
Windows 2000 Site	Exchange 5.5 Site
A Windows 2000 site requires high bandwidth, reliable, permanent network connections between all servers.	An Exchange 5.5 site requires high bandwidth, reliable, permanent network connections between all servers.
A Windows 2000 site is a collection of IP subnets based on the physical network topology.	An Exchange 5.5 site is a logical grouping of servers for administrative purposes.
A Windows 2000 site has no relationship with the Active Directory domain structure and does not include a unit of namespace.	An Exchange 5.5 site includes a unit of namespace in the X.500 structure.
A Windows 2000 site has no administrative implications.	An Exchange 5.5 site defines an administrative boundary.
Exchange 2000 uses routing groups to define message flow. Routing groups are independent of Windows 2000 site boundaries.	An Exchange 5.5 site defines message routing in the Exchange organization.

Exchange 2000 Server uses Windows 2000 sites to locate domain controllers or global catalog servers for address book lookups and to access configuration information. Beyond this, Exchange relies only minimally on Windows 2000 sites.

Administrative groups
An Exchange 5.5 site was used to organize servers for two often contradictory purposes. An Exchange site was a logical administrative boundary used to delegate management responsibility for particular servers. A site was also used to layer the Exchange organization on top of the physical network topology; it defined the message routing boundaries. The Exchange 5.5 site concept has been replaced in Exchange 2000 Server with two separate concepts: administrative groups and routing groups.

An Exchange 2000 administrative group defines a logical administrative boundary. An administrative group is a collection of Exchange servers and configuration objects that are grouped together because they will be managed by a common IT management group. An administrative group can contain multiple Exchange servers, routing groups, policies, and public folder trees.

NOTE: If you have a mixed environment that contains both Exchange 2000 and Exchange 5.5 servers, an administrative group operates just like an Exchange 5.5 site.

You define an administrative group so you can delegate administrative responsibility. For example, if you have three regional IT management teams that each manage the Exchange servers in their respective regions, you can create three administrative groups containing the appropriate servers.

You can then grant the separate IT management teams appropriate permissions to the administrative groups. The Active Directory then automatically assigns these permissions to servers and other objects within the administrative groups.

Administrative groups need to be carefully planned because Exchange 2000 administrative groups have one of the same limitations that was a problem with Exchange 5.5 sites: Once you assign servers and mailboxes to an administrative group, it is difficult and requires special utilities to move the servers and mailboxes to another administrative group.

MAPI clients store sender addresses as distinguished names that are constructed based on the administrative group in which the user’s mailbox resides. If you move a user mailbox from one administrative group to another, the user’s distinguished name will change, and users will not be able to reply to e-mail messages that the user sent prior to being moved.

NOTE: You can work around the inability to reply to messages sent prior to moving a user by inserting an X.500 address type on the moved entity to match the previous location of the user.

This problem does not exist for Internet clients because they use SMTP addresses rather than distinguished names. As long as an Internet user’s SMTP address does not change, users will not have any problem replying to e-mail messages.

Enabling display of administrative groups and routing groups
Viewing administrative groups is disabled by default. The following procedure can be used to enable displaying administrative groups and routing groups:

Launch the System Manager from the Windows 2000 Start menu by selecting Programs, Microsoft Exchange, System Manager.
Right-click on the Exchange organization and select Properties to display the organization properties ( Figure 7).
Select the Display administrative groups check box to allow the administrative groups to be displayed and select the Display routing groups check box to display the routing groups.
You must restart the Exchange System Manager after enabling display of administrative groups and routing groups.

Creating an administrative group
The following procedure can be used to create an administrative group:

Launch the System Manager from the Windows 2000 Start menu by selecting Programs, Microsoft Exchange, System Manager.
Right-click on Administrative Groups, and select New, Administrative Group.
On the General tab, enter a name for the administrative group ( Figure 8).
Use the Administrative note field on the Details tab to enter additional information about the administrative group.
Select OK when finished.

Routing groups
Exchange 2000 routing groups define physical routing boundaries and are based on the underlying physical network connectivity and network bandwidth. All Exchange servers within a routing group communicate over reliable, high bandwidth, permanent network connections.

Messages sent from one Exchange server to another within the same routing group go directly between the two servers. However, if the two Exchange servers are in different routing groups, messages must be routed to a bridgehead server in the sender’s routing group, then to a bridgehead server in the recipient’s routing group, and finally to the recipient’s Exchange mailbox server.

Unlike administrative groups, it is not difficult to move an Exchange server from one routing group to another.

Creating a routing group
You must create a routing group container under your administrative groups container before you can create a routing group. The following procedure can be used to create a routing group container:

Launch the System Manager from the Windows 2000 Start menu by selecting Programs, Microsoft Exchange, System Manager.
Select Administrative Groups, select the administrative group that will contain the routing group, and select Routing Groups.
Right-click on Routing Groups and select New, Routing Group.
On the General tab, enter a name for the new routing group, and then select OK.

Schema
The schema defines all of the objects, called classes, that can be stored in the Active Directory. For each object class, the schema defines the attributes that must be included in an instance of the class, the additional attributes that each instance may have, and the object classes that may be the parent of the object. The schema itself is also stored in the Active Directory. This allows applications to query the Active Directory to identify the available objects and attributes that can be used to administer the object.

A default schema is created when you install the first domain controller in a new forest. This default schema contains class definitions for commonly used objects attributes such as systems, printers, groups, and users.

Subsequent changes to the schema, including those required for Exchange process, result in a complete replication of the global catalog. This includes all objects and all attributes, not just the attributes that have been changed or added. For this reason, you should apply the Exchange-specific schema updates while your Windows 2000 forest is still small. In fact, before you can install Exchange, you must apply the Exchange-specific schema updates. Before you can install Exchange, you must first prepare the forest and each domain that will contain an Exchange server. You can use the following procedure to prepare the forest:

Insert the Exchange 2000 Server CD-ROM into your CD-ROM drive.
Select Run from the Windows 2000 Start menu. Enter x:\setup\i386\setup.exe /ForestPrep where x is your CD-ROM drive. Select OK to start the setup program.

You must run ForestPrep only once per forest. Updating the schema to add the Exchange takes a considerable amount of the time while several LDAP Directory Interface Format (LDIF) files are applied. The Schema Master for the forest must be available for the duration of this process, which can often take a half an hour or longer depending upon the server and network speed. The ForestPrep procedure extends the schema to include over 150 additional classes and over 800 additional attributes such as the user’s display name and location. In addition, 270 attributes are marked for replication to the global catalog. All of the Exchange-specific attributes have names that begin with ms-Exch. Table 2 lists some of these common Exchange user attributes.

You must run the DomainPrep procedure for every Windows 2000 domain that will contain an Exchange server. DomainPrep is used to identify the address list server and to set permissions within the domain. You do not need to run DomainPrep in a domain until you are ready to install Exchange. You can use the following procedure to run DomainPrep:

Insert the Exchange 2000 Server CD-ROM into your CD-ROM drive.
Select Run from the Windows 2000 Start menu. Enter x:\setup\i386\setup.exe /DomainPrep where x is your CD-ROM drive. Select OK to start the setup program.

As your needs change, you may decide to modify the schema to accommodate your changing requirements. For example, you may want to include an additional user attribute such as the user’s department in the global catalog. A change such as this is quite easy using the Schema Manager, if you have the appropriate permissions. Every Active Directory object, including schema objects, is protected by Access Control Lists (ACLs).

Schema changes may also be made by other applications. Like Exchange 2000, other applications may automatically extend the schema to support their requirements.

Regardless of whether you make the schema changes or an application makes the schema changes, you should be aware that the schema changes will force a complete replication of the global catalog. All objects and all attributes — not just the modified or added attributes — will be replicated to every global catalog server. Depending upon the number of global catalog servers and the size of the active directory, this complete replication process can cause significant network overhead. For this reason, schema updates should not be done frequently. If possible, they should be done during the early part of your Windows 2000 implementation while the forest is still small.

Creating a Schema Manager MMC console
Improper use of the Schema Manager snap-in can cause serious problems, so the snap-in is not available by default. Use the following procedure to enable the snap-in and create a Schema Manager MMC console:

Select Run from the Windows 2000 Start menu. Enter regsvr32 schmmgmt.dll as the command to run. The system will display a dialog box that says "DllRegisterServer in schmmgmt.dll succeeded." Select OK.
Start the Microsoft Management Console from the Windows 2000 Start menu by selecting Run. Enter MMC as the command to run and select OK. An empty MMC console window will be displayed.
Select Add/Remove Snap-in from the Console menu.
Select Add to display a list of the available MMC snap-ins ( Figure 9).
Select the Active Directory Schema snap-in, and select Add. The selected snap-in will be added to the list of snap-ins for this MMC console. Select Close to return to the Add/Remove Snap-in window.
Select OK on the Add/Remove Snap-in window.
Select Options from the Console menu.
Set the following options on the Console tab:
- Enter Schema Manager as the name for the new MMC console in the field at the top of the Options window.
- Use the Console mode drop-down list to select User mode — full access. This mode grants users full access to all window management commands and to the console tree provided. It prevents users from adding or removing snap-ins or changing console properties.
- Select Enable context menus on taskpads in this console to display pop-up context-sensitive menus.
- Select Allow the user to customize views if you want to allow customizing by the user.
Select OK when you have completed entering options.
Select Save As from the Console menu.
Enter Schema Manager.msc into the File name field and select Save to save the new MMC console.

Tagging attributes for Global Catalog replication
You can mark additional attributes for Global Catalog replication using the following procedure.

Start the Schema Manager console from the Windows 2000 Start menu by selecting Programs, Administrative Tools, Schema Manager.
Select Active Directory Schema, Attributes in the left pane.
In the right pane, locate and double-click on the attribute that you wish to replicate to the Global Catalog to display the attribute properties ( Figure 10).
Select the Replicate this attribute to the global catalog check box to tag this attribute for replication, and then select OK.

NAMESPACE AND NAME RESOLUTION

Domain name system (DNS)
Exchange 2000 is a network-based product that resides in the applications layer of the TCP/IP Reference Model. As a network-based product, it is highly dependent upon the network transport and protocol support provided by the underlying network. While the Exchange server packages e-mail messages for delivery, it is actually the underlying network that transports the message to the recipient’s environment. Client systems also use the network infrastructure to communicate with the Exchange servers. Before a client or server can communicate with another server, it must be able to translate the target server’s name into an address. A properly functioning name resolution system is an essential component of any networked environment.

Windows NT 4.0 and Exchange Server 5.5 used two methods of name resolution:

Windows Internet Naming Service (WINS). WINS provided Net-BIOS over TCP/IP (NetBT) name resolution for Windows NT 4.0. WINS was the preferred name resolution method for Windows NT 4.0 primarily because is supported dynamic name registration.
Domain Name System (DNS). DNS provided Winsock-based name resolution. By default, both Exchange and Outlook used DNS for name resolution since they used the Winsock layer for communications.

Windows 2000 and Exchange 2000 use DNS for name resolution. Neither Windows 2000 nor Exchange 2000 will operate if you do not have a DNS service running on your network. While Exchange has always relied upon DNS, the extensive use of DNS by the operating system is new. All domain names and the Windows 2000 namespace are stored in DNS. The location of domain controllers is stored in DNS using Service Resource Records (SRV-RR) to map service names. DNS, rather than WINS, is now used for logon validation and domain validation.

DNS is primarily used to record the names and locations of systems and services, while the Active Directory is used to store object and attribute information. Windows 2000 uses LDAP to find Active Directory objects and elements. Table 5 compares the relative advantages of DNS and LDAP for locating information.

The DNS naming scheme is standards-based (RFC 1034 and RFC 1035) and provides maximum interoperability with Internet technologies. The DNS used in your Windows 2000 environment must also support Service Resource Records (RFC 2052). It is also advisable that the DNS you choose also support the following features:

Dynamic Update (RFC 2136). With dynamic updates, the netlogon service on the domain controller will automatically register domain services and sites. This reduces the need to manually update DNS records and reduces human errors.
Incremental Zone Transfers (RFC 1995). Incremental Zone Transfers reduce the network bandwidth requirements for replicating information to all DNS servers.

The DNS service that is supplied with Windows 2000 supports all of these features.

Your DNS strategy needs to be planned early and implemented before you deploy Windows 2000. Carefully consider the names you will use because after you choose and deploy the names, any changes may be difficult.

The DNS root domain name will be the name used for the root of your Windows 2000 forest. The root domain name should be meaningful, available, registered, and stable. Management and legal approval are usually required for DNS root domain names since these are known to the public.

You will need to determine the zones you need to create. You should ensure that you have a zone for each domain so that you can integrate DNS into the Active Directory if you decide to do so at some point, either immediately or in the future.

You also need to consider the names that will be used. Remember that each system will be represented by a fully qualified DNS name (e.g., server89.dallasdomain.compaq.com). The names should be meaningful, but they should also be short because the fully qualified name can become rather lengthy and difficult to use. You should use only characters that are part of the character set permitted for use in DNS host naming. These characters include all letters (both upper case and lower case), numbers, and the hyphen (-).

TABLE 5: DNS and LDAP
Domain Name System (DNS)	LDAP
Hierarchical, distributed, partitioned, replicated	Emerging standard
Most-used naming service	Great for fine-grained attributes and look-ups
Great for finding systems	LDAP is used to access objects inside a domain
Not very good for accessing fine-grained attributes
Used to find LDAP server that is a domain controller

Exchange 2000 Server relies upon specific DNS services. Exchange 2000 replies upon Service Resource Records (SRV-RR) to locate domain controllers, global catalog servers, and sites. Exchange does not enter any Service Resource Records for the Exchange servers. Instead, Exchange servers are registered in DNS as Address (A) records, and Exchange 2000 uses these Address records to locate other Exchange servers in the forest. Exchange 2000 also uses DNS Mail Exchanger (MX) records to identify Exchange and non-Exchange mail servers that support different domain namespaces. SMTP (including the Exchange SMTP connector) uses the MX records to locate preferred SMTP mail servers.

In addition, some Exchange 2000 components use Internet Information Server (IIS) Web services. For example, Outlook Web Access (OWA), Instant Messaging, and Conferencing all have an associated namespace. DNS aliases can be used to provide users with a more friendly representation of the namespace.

By default, the Windows 2000 domain name as registered in DNS is used as part of the e-mail address for users within the domain. For example, users in the dallas.compaq.com domain would have users of the form user-name@dallas.compaq.com. However, this need not be the case. Although a user’s Windows 2000 logon name might be username@dallas.compaq.com, the generation of e-mail addresses can be controlled using the following procedure:

Start the System Manager from the Windows 2000 Start menu by selecting Programs, Microsoft Exchange, System Manager.
Select Recipients, Recipient Policies, and then double-click Default Policy to display the Default Policy Properties ( Figure 11). The E-Mail Addresses tab contains the default e-mail address general rules.

Windows Internet naming service (WINS)
WINS and NetBIOS are still supported by Windows 2000. In fact, Windows 2000 has enhanced WINS by adding manual tombstoning, improved management tools, enhanced filtering, and dynamic record deletion. While Windows 2000 no longer relies upon WINS, WINS is still used by Windows NT 4.0 domain members in a mixed environment and by legacy applications.

You should evaluate your use of WINS. For an existing Windows NT environment that is migrating to Windows 2000, you will need to keep WINS running for coexistence. You should consider how names would be supported in both DNS and WINS because clients may be using either one to access resources.

Page: 1, 2, 3 , 4

ADS BY GOOGLE