Lesson 1: General Network Dependencies of Exchange 2000 Server

Exchange 2000 Server does not make much sense used as a stand-alone application on a single computer. Clients must be able to connect to their home servers over a computer network, where their mailboxes reside, and servers need to locate each other to transfer messages. Inevitably, the traffic in a network rises when users increasingly begin to use their messaging infrastructure for most of their communication, such as for regular e-mail, groupware, and instant messaging, and perhaps also for online conferencing. Smart placement of Exchange 2000 servers in the network can help to minimize this impact. You need to review your corporate network to find the best server locations, identify potential points of network failures, and determine options for improving the network’s efficiency.

This lesson addresses several important network elements that you need to consider when creating detailed deployment plans for Exchange 2000. Several network services—although operating independently of Exchange 2000 Server —have a significant influence in the architecture of the messaging organization. In this lesson, you can find guidelines for documenting a computer network.

After this lesson, you will be able to

  • Identify important network components that must operate reliably to support the deployment of Exchange 2000 Server
  • Identify infrastructure bottlenecks that may limit the performance and quality of your messaging environment

Estimated time to complete this lesson: 60 minutes

Understanding the Network Dependencies of Exchange 2000 Server

Messaging refers to a family of communication services that reside at the application layer, which means that they are on top of the Presentation, Session, Transport, Network, Data Link, and Physical Layers in the Open Systems Interconnection (OSI) reference model. In other words, the messaging services of Exchange 2000 and other platforms rely on networking components, such as TCP/IP and DNS, for all of their communication. Any problems that prevent your systems from locating or communicating with each other implicitly prevent your messaging infrastructure from functioning, so the quality of your messaging environment depends largely on the reliability of your computer network.

Network Topology

At the lowest level—the physical level—networks are generally classified as LANs, MANs, and WANs, and each of these types uses specific technologies to establish the computer network. Specialized networking equipment, such as switches and routers, is required to bring these technologies together and build a global infrastructure (Figure 3.1). The global network topology affects the architecture of your messaging environment to a great extent, as discussed later in this lesson.

LAN segments connect systems separated by a short distance, such as the computers in a particular office building. Typical LAN technologies are token ring and Ethernet. LANs have high bandwidth and low latency, so all users should be able to access all network resources right away. For this reason, you are free to choose a server location that best suits your needs.

MANs, on the other hand, interconnect locations in a distinct geographical area, such as multiple offices within a single city. The cost of bandwidth increases dramatically when a network must cross a greater distance, so you must carefully decide where your servers will be located. Do you prefer to distribute your servers across all connected LANs, or would you rather keep all servers central for more convenient systems management? MANs are generally connected with circuits, such as a T-1 or a T-3, which provide sufficient bandwidth for a centralized server farm. A discussion of the advantages and disadvantages of centralized and decentralized deployments follows later in this lesson.

Figure 3.1 - LANs, MANs, and WANs

WANs, to complete the list, connect geographically separated areas to build genuine global networks. WANs can be established over dial-up or leased telephone lines, satellite connections, or other media. If your corporate network spans a WAN, review its topology carefully to best place your servers. Not all WAN connections support every type of communication. For instance, it would not be possible to use a Messaging Application Programming Interface (MAPI)-based client, such as Outlook 2000, and connect to a server over a network link that does not support remote procedure calls (RPCs), such as a high-latency X.25 connection or an Internet connection where the TCP port for the RPC endpoint mapper (port 135) is blocked.

Bandwidth and Net-Available Bandwidth

The bandwidth of your network connections describes their total data transfer capacity in bits per second (bps). The higher the bandwidth, the faster the data transfer, which means more data can be transferred in a given period of time. Typical LANs have a bandwidth of 4, 10, 16, or 100 megabits per second (Mbps), or 1 gigabit per second (Gbps). The capacity of WANs, on the other hand, can vary from below 9600 kilobits per second (Kbps) to more than 40 Mbps.

Your network’s total bandwidth, however, does not necessarily indicate how much data your messaging clients and servers can actually transfer per second. For instance, your users may already have consumed a significant amount of bandwidth with file-based operations if they work with a large amount of files over the network, such as user profiles maintained on a file server. Of course, only that fraction of the total bandwidth that has not been consumed by any other network applications or processes is available to Exchange 2000 Server and its clients. This fraction is often called the net-available bandwidth. It is the net-available bandwidth that actually determines the performance of your Exchange 2000 organization.

Using a data packet capturing and analysis tool, such as Microsoft Network Monitor, you can determine the net-available bandwidth by measuring the amount of traffic generated in the network (the bandwidth consumption) over a given period of time: net-available bandwidth = total bandwidth – bandwidth consumption.

Note


It is not possible to fully consume the total bandwidth of a network link with data transfer. Collisions (two devices trying to transmit data at the same moment), repeated transmissions (due to data corruption along the way from the sending to the receiving station), protocol overhead (information to maintain connection states), and broadcasts (data packets transmitted to all stations in the network) decrease the net-available bandwidth.

Internet Access Points

In addition to ensuring that you have enough bandwidth to handle the workload, you should also consider the costs of providing that bandwidth. Data transfer in LANs is usually inexpensive, but MANs and WANs can generate substantial transmission costs. To minimize these costs, you may find it attractive to optimize your WANs by means of Internet connections. Virtual private networks (VPNs), established via short-distance connections to a local Internet service provider (ISP), are an interesting low-cost alternative to long-distance leased lines. You can also use VPNs to support individual remote users who are able to connect to the corporate network via the Internet. However, the downside of Internet connections is increased security risk. You need to protect your corporate network through an arrangement of firewalls (Figure 3.2). The location of your Internet access points and their architecture is an important design factor for your messaging organization.

Figure 3.2 - A demilitarized zone with one proxy and one SMTP relay host

A firewall prevents Internet users from accessing computer systems in the corporate network. All communication between the Internet and the internal network is routed through an arrangement of proxy servers and relay hosts placed in an intermediate area outside the internal network, which forward the information between the Internet and the internal network. This area is called a perimeter network or demilitarized zone (DMZ). Connections are only allowed to dedicated systems in the DMZ, meaning all direct connections between the Internet and the internal network are blocked. A firewall greatly improves security because it prevents direct access to any internal systems, but it also affects your options for accessing internal Exchange 2000 resources over the Net. You can read more about integration with the Internet in Chapter 8, "Designing Hosted Services with Microsoft Exchange 2000 Server."

Dial-Up Connections

You can classify any dial-up links, such as analog or Integrated Services Digital Network (ISDN) lines, as WAN connections. Your remote users can use them to connect to the corporate network from locations where no other network connection exists. You can also use dial-up connections to connect different locations of your network together or provide a backup line in addition to the primary WAN.

Dial-up connections require the remote computer to dial into a remote access server (RAS) in the local network. The local RAS system authenticates the incoming user or system and only accepts the connection attempt if the user is authorized to access the network remotely, which is a special privilege granted by the network administrator. Once the connection is established, the communication can take place as if the remote computer is located in the LAN (Figure 3.3). The RAS server forwards the data between the remote station and the systems in the local network. It also performs a protocol translation if required (that is, it acts as a multiprotocol router).

Figure 3.3 - Dial-in and dial-out connections

Remote users typically use dial-up networking to connect with their clients to a remote access server. Microsoft Outlook 2000 in a remote client configuration, for instance, uses dial-up networking. Connector components of Exchange 2000 Server, on the other hand, do not establish dial-up connections themselves. They require a demand-dial router in the network to transfer messages to other systems over dial-up links. A local demand-dial router (the calling router) connects automatically to a demand-dial router in the remote network (the answering router) when a station in the local network requests a connection to a system in the remote network, as shown in Figure 3.3. The Exchange 2000 server may experience a brief delay during connection establishment, but once established, the dial-up connection is used just as any other network link. You can use the Routing and Remote Access Service (RRAS) of Windows 2000 to configure a Windows 2000 server as a RAS server and demand-dial router.

Communication Protocols

Physical connectivity is not the only requirement for communication to take place. Your computers must also use and understand the same protocols; otherwise, there is no data transfer. Communication protocols define the rules and procedures that communication partners must follow to transfer data over the physical links. Protocol parameters must match on all systems to ensure a functioning environment.

Examples of protocols typically used in PC-based networks are TCP/IP, Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX), NetBIOS Enhanced User Interface (NetBEUI), and AppleTalk. Exchange 2000 Server requires TCP/IP in any case because this system relies heavily on Internet-based networking components, such as the Windows 2000 SMTP service and DNS, but you may also have to install other protocols on the server, such as IPX/SPX or AppleTalk, to provide access to Exchange 2000 resources from Novell NetWare or Apple Macintosh clients.

Name Resolution Mechanisms

Even with functioning physical connections and matching protocols, communication problems can occur if your computers cannot locate each other on the network. This is seldom an issue in a LAN, where broadcasts work and are used for name resolution, but MANs and WANs block broadcasts (hopefully) and require additional services to resolve user-friendly computer names into computer-friendly network addresses. Windows 2000, and therefore Exchange 2000 Server, supports the TCP/IP host name resolution through DNS and the HOSTS file and supports the network basic input/output system (NetBIOS) name resolution through Windows Internet Naming Service (WINS) and the LMHOSTS file. Other mechanisms, such as the Service Advertising Protocol (SAP) for Novell NetWare-compliant name resolution, are used in an IPX network.

Note


Exchange 2000 Server relies on host name resolution to locate other servers and foreign SMTP-based messaging systems in the network.

Host Name Resolution

Originally, a simple HOSTS file was used to associate IP addresses with host names, but a simple text file does not scale well to a large number of IP addresses. DNS overcomes the limitations of HOSTS, and now computers in TCP/IP-based environments query DNS to retrieve IP addresses for host names, although they may still use a HOSTS file as well.

DNS is a distributed database system structured according to the hierarchy of Internet domains. Fully qualified domain names (FQDNs) are used to identify each host in the network. FQDNs consist of a top-level domain, a first-level domain, possibly subdomains, and the host name. Two fictitious FQDNs are host1.microsoft.com and host1.sub2.treyresearch.net. Reading from the right to the left, you can examine the hierarchy of the domain structure (Figure 3.4).

Figure 3.4 - The hierarchy of fully qualified domain names

The DNS tree is split into individual portions called zones, which are managed as separate entities by different DNS servers. A zone is a database that contains the resource records (RRs) for all those hosts that exist within the zone’s domains. The first record in the zone file—the start of authority (SOA) RR—identifies the primary DNS server that maintains all the IP address information for the zone. The advantage of this hierarchically arranged DNS tree is that individual DNS servers do not need to maintain complete IP address information for the entire environment, such as the whole Internet. They only need to take care of their own domains and subdomains. Queries that cannot be resolved from local zone files are escalated to another DNS server somewhere in the network, such as a root DNS server in the Internet, that needs to resolve the requests or escalate them further. DNS is discussed in detail in the Windows 2000 Server product documentation.

Windows Internet Naming Service

Basically all Microsoft networking products support NetBIOS. You can use an LMHOSTS file to map IP addresses to NetBIOS names, but address information can also be maintained dynamically using WINS. The LMHOSTS file works similar to the HOSTS file. WINS, in turn, overcomes the limitations of LMHOSTS, as DNS does for HOSTS. Similar to DNS, WINS is a separate network service available in the Windows 2000 Server software package.

Exchange 2000 Server and Microsoft Outlook 2000 running on Windows 2000 prefer to use DNS and do not require WINS, but clients running on Windows NT 3.5, Windows NT 3.51, Windows NT 4.0, Windows 95, or Windows 98 need the NetBIOS name service to locate domain controllers and other resources in the network. Hence, WINS continues to play an important role in mixed environments. You should not decommission WINS without careful preparation and thorough testing. For more information about WINS, see the Windows 2000 Server product documentation.

Supporting Network Services

Further network services that may be required in the enterprise include the Dynamic Host Configuration Protocol (DHCP), Gateway and Client Services for NetWare (GSNW), and Services for Macintosh. Windows 2000 DHCP integrates with DNS and Active Directory to simplify the management and assignment of IP addresses and other TCP/IP parameters to workstations and servers. DHCP greatly facilitates the task of administering TCP/IP across the entire network. GSNW, on the other hand, is an essential component for integrating Windows 2000 (and Exchange 2000 Server) in a Novell NetWare-based environment that does not support native TCP/IP. Traditional Novell NetWare networks use IPX/SPX, which Windows 2000 supports through its NWLink IPX/SPX- compatible protocol. GSNW requires NWLink to communicate with NetWare systems. Services for Macintosh gives Macintosh users the ability to access a computer running Windows 2000 Server in the same way they connect to an AppleShare server. Macintosh users can also use TCP/IP instead. The Windows 2000 Server product documentation contains more information about DHCP, GSNW, and Services for Macintosh.

Documenting the Current Network Infrastructure

Of course, your project team needs to gain an exact overview of the existing infrastructure and its network services to make reliable design decisions. However, manually documenting every network device can quickly turn into a very puzzling task. You should use helpful tools and utilities wherever possible, such as the Windows 2000 System Information utility (WINMSD.EXE) or Microsoft Visio Enterprise 2000, and focus on a graphical representation of the existing environment. Graphical representations are much more informative than endless tables of technical parameters. Depending on the size of your network, a large diagram showing all the network components may be sufficient, or you may provide several smaller diagrams that focus on more specific characteristics, such as the global infrastructure and the LANs in each geographical location. When documenting your environment, use Figures 3.5 through 3.7 as examples.

Tip


If all of your network devices support the Simple Network Management Protocol (SNMP), Microsoft Visio Enterprise 2000 can create network diagrams automatically for you.

Document the existing environment in the following order:

  1. The WAN topology connecting the geographically separated sites of your organization
  2. The LAN topology in each location, including brief information about servers, workstations, network protocols, and the services provided in each network segment
  3. The network services in each LAN, including the configuration of Internet access points, DNS, WINS, DHCP, and components for interoperability with Novell NetWare, Apple Macintosh, or other systems
  4. The configuration of servers and workstations, including their hardware, operating system, installed applications, and their configuration
  5. The naming conventions for servers, workstations, and users, as well as other organizational standards

Tip


You can find a Microsoft Excel workspace with several worksheets to document a network environment in the \Chapter03\Worksheets directory on the Supplemental Course Materials CD. The filename is CURRENT_ENVIRONMENT.XLS.

WAN Topology

If you plan to implement a global or worldwide Exchange 2000 organization, your project team needs to gain a complete overview of the various locations; the number of server systems, workstations, and users in each location; and the characteristics of the WAN connections between them as well as the total bandwidth for each individual link. As mentioned earlier, it is a good idea to provide a diagram to visualize the WAN topology (Figure 3.5).

When documenting the WAN topology, include the following information:

  • A high-level WAN diagram showing the location of sites and the links between them
  • The location of Internet access points and the methods used to connect to the Internet (that is, permanent or dial-up connections)
  • The number of servers and workstations in each location and their operating systems
  • The number of users in each location
  • The type and bandwidth of each WAN connection

Figure 3.5 - A sample diagram of a WAN topology

MAN/LAN Environment

Working down from global information toward more detailed data, the LAN environment should be described next for each location individually. If your deployment affects more than one LAN in a particular geographical location, describe all of them and how they are interconnected (Figure 3.6).

Figure 3.6 - A sample diagram of a MAN/LAN topology

When documenting LAN topologies, include the following information:

  • A diagram of the LAN topology
  • The communication protocols used within each network segment to determine if and how all messaging clients are able to connect to their servers
  • The infrastructure for remote access points, such as RRAS servers and the maximum connection speed of dial-up connections
  • The physical network structure, including information about the network technology (that is, token ring or Ethernet) and devices (such as hubs, switches, routers, gateways, and so on)
  • The servers and workstations within each network segment
  • The architecture of Internet access points and the systems in the DMZ

Essential Network Services

In addition to the physical structure, you also need to document the configuration of important network services, including DNS, WINS, DHCP, and so on. This information will help your project team determine where and how the computers running Exchange 2000 Server can register and locate other systems in the network.

When documenting network services, include the following information:

  • The internal and external DNS servers that maintain the zones in your organization and the current internal and external DNS names for the organization (Figure 3.7). You should also include information about the version of DNS being used, such as Microsoft DNS Server, and the team that is responsible for maintaining DNS.
  • The network’s DHCP configuration, including information about which systems use DHCP and which have statically assigned IP addresses. Do not forget to document all global settings, such as lease intervals and scope settings.
  • The primary and backup WINS servers that the workstations in each network segment use for NetBIOS name registration and resolution.
  • The names and configuration of systems offering other services, such as GSNW or Services for Macintosh, required to support client connectivity.

Servers and Workstations

Your documentation should also include information about existing servers and workstations to determine which ones could potentially run Exchange 2000 Server or Outlook 2000. Keeping track of typical workstation configurations, for instance, allows you to clarify, among other things, whether the rollout of Outlook 2000 requires major upgrades to the desktop computers. Precise system information is also essential when developing backup and disaster recovery strategies, which are covered in detail in Chapter 11, "Designing a Disaster Recovery Plan for Microsoft Exchange 2000 Server."

Figure 3.7 - A DNS environment with internal and external DNS servers

Tip


You may use Microsoft Systems Management Server (SMS) or another network management solution to create an inventory database for your environment. Querying this database, you could quickly check for computers that are able to run Exchange 2000 Server or Outlook 2000 without additional hardware investments.

When documenting servers and workstations, include the following information:

  • Any hardware standards, including manufacturers, type and number of CPUs, the amount of random access memory (RAM) and whether it can be expanded, available hard disk space, the type of network cards, and any special hardware that is not on the Windows 2000 Server Hardware Compatibility List (HCL)
  • Any server monitoring tools in use, such as Microsoft SMS, Computer Associates Unicenter TNG, Hewlett Packard OpenView, or IBM Tivoli
  • The operating systems, communications protocols, and any special protocol parameters of servers and workstations
  • The role of each server in the corporate network
  • The software and any existing strategies for backup and disaster recovery

Organizational Standards

If you plan to install new servers for Exchange 2000, you need to know the existing naming conventions to define the new server names according to the standards of your organization. Do not forget to include this information in your documentation. It is difficult to change the name of an Exchange 2000 server after its installation in the production environment. If your organization does not have a naming convention in place, you may want to establish one for your project to coordinate the assignment and use of server and workstation names.

Many organizations use a name convention based on a three-character code for the computer’s location plus two digits for a reference number and three additional characters for the computer’s role (such as NYC-01-E2K). Others may prefer to include information about the operating system, for instance, three characters for the operating system, two to four for the computer’s role plus a role-specific reference number, followed by a location identifier of up to five characters (such as W2K-E2K1-SFBA1). Small companies with an easily comprehensible number of computers often prefer less involved names, such as those of Greek gods, famous personalities, or geographical locations. Of course, Microsoft does not recommend these exotic naming conventions, but Exchange 2000 works fine on a computer called Mercury-01, too. Because of NetBIOS dependencies, restrict the length of your computer names to fewer than 15 characters.

Note


Try to avoid variable information in your naming conventions, such as Service Pack numbers or initials of administrators.

When documenting the naming conventions of your organization, include the following information:

  • Conventions for server and workstation names
  • Naming conventions for domains
  • Policies for user names and passwords

Analyzing and Optimizing the Network Topology

The documentation of the existing environment serves two purposes: It provides your project team with essential background information to design the Exchange 2000 organization, and it allows you to determine potential bottlenecks and shortcomings in the current infrastructure, which you need to address in your risk management plan to ensure a smooth production rollout. It is tempting to think that the deployment of Exchange 2000 would be a great opportunity to redesign the overall network and implement numerous changes. Withstand this temptation, however, because any network optimization will cost time and resources and will increase the complexity of your project. Many projects fail because they get out of hand—and they get out of hand because the project team loses its focus. Carry out only those changes that are absolutely necessary to achieve the required level of functionality and performance in the Exchange 2000 organization. Stay focused on those objectives that you have outlined in your vision and scope document and postpone optimizations that are not mission-critical for a follow-up project. The purpose of the vision and scope document is discussed in Chapter 2, "Preparing for a Microsoft Exchange 2000 Server Deployment Project."

The performance of an Exchange 2000 organization primarily depends on the following characteristics:

  • Hardware configuration of Exchange 2000 servers
  • Available data transfer capacity in the network
  • Reliability of network communication, including physical links and devices as well as transport protocol configuration
  • The configuration of Active Directory, DNS, and other name resolution services

System Requirements for Exchange 2000

If you plan to install Exchange 2000 Server on an existing system in your environment, review your server and workstation documentation carefully to avoid overloading any system. You need to consider not only the available hardware but also the other services that the system is supposed to provide to the users (see Figure B.3 in Appendix B). Every active process consumes server resources. For this reason, many organizations choose to run a separate server for each network application. A Global Catalog (GC) server or domain controller would not have to also run Exchange 2000 Server. Ideally, Exchange 2000 Server does not need to share its hardware with any other network application.

Tip


If you plan to install Exchange 2000 on an existing server already running other network applications, monitor the total processor and memory usage to find out whether the system will be able to handle the load of Exchange 2000.

Theoretically, you can create an unlimited number of mailboxes and public folders on a single Exchange 2000 server. In practice, however, you are restricted by the power of the server hardware (that is, processor speed, amount of RAM, hard disk capacity, speed of backup system, and so on) and on other, more practical considerations. Table 3.1 lists the basic hardware requirements for a test server as well as a production server for approximately 1000 to 2000 users. Make sure that your hardware is on the HCL. You can read more about the design of server hardware for optimum fault tolerance and performance in Chapter 10, "Designing Fault Tolerance and System Resilience for Microsoft Exchange 2000 Server."

Table 3.1 Basic Hardware Requirements for Exchange 2000 Server

Hardware Requirements for a Test Server Hardware Requirements for Approximately 1000–2000 Users

Intel Pentium or compatible CPU at 133 MHz or higher

2–4 Intel Pentium III or compatible CPUs at 500 MHz or higher

128 MB–256 MB of RAM

512 MB–1 GB or more of RAM

2-GB system drive with 200 MB free disk space

2 × 4 GB (RAID-1) system drive or larger

2-GB data drive with 500 MB available disk space for Exchange 2000 Server

4 × 12 GB (RAID-5) data drive or larger/more disks

Network interface card (NIC), video adapter

100 Mbps NIC or faster, video adapter

Exchange 2000 Server requires the following software:

  • Windows 2000 Server, Advanced Server, or DataCenter Server
  • Windows 2000 Service Pack 1
  • Internet Information Services (IIS)
  • SMTP and Network News Transfer Protocol (NNTP) services

Note


Microsoft provides a tool called Load Simulator to check the behavior of an Exchange 2000 server in a test lab under altering conditions. Performance tests allow you to determine, among other things, the required server hardware for your number of users. Load Simulator is included in the Microsoft Exchange 2000 Server Resource Kit.

Server Names

Windows 2000 has similar NetBIOS naming requirements to Windows NT 4.0. However, NetBIOS names can contain characters not supported by DNS, including these special characters: ! @ # $ % ^ & ( ) _ ‘ { } . ~. Yet, Windows 2000 and Exchange 2000 Server require DNS to locate resources in the network. Therefore, if your existing naming conventions are based on any of the special characters, you should change the naming standards. As mentioned earlier, you should define the names of your Exchange 2000 servers before you start the production rollout (see Figure B.4 in Appendix B). Due to the tight integration with DNS, names of Exchange 2000 servers should only contain alphanumeric characters (A–Z, a–z, 0–9) and hyphens.

Note


Request for Comments (RFC) 1035 states that only letters, numbers, and hyphens can be used in host names, but for easy integration with down-level systems, Microsoft DNS in Windows 2000 supports nonstandard host names as well. Nevertheless, Exchange 2000 servers, especially those connected to the Internet, should comply with RFC 1035 to keep the configuration of external DNS servers straightforward.

Server Locations

One fundamental question in deployment planning is where to place the servers. Would you prefer to install an Exchange 2000 server in each LAN segment for faster server response times, or would you like to concentrate all resources on fewer servers in a central location for simplified system administration and maintenance? Both approaches have advantages and disadvantages, as shown in Table 3.2. Deploying Exchange 2000 Server in all network segments may not be an option if administrators are not available in the branch offices, for instance. Placing all Exchange 2000 servers in a central location, on the other hand, may create a substantial strain on your WAN links because the WAN then must handle all the client/server traffic. The communication between clients and servers is much harder to control than the transfer of e-mail messages between servers. It is easier to control a few servers than hundreds or thousands of clients.

Table 3.2 Advantages and Disadvantages of Centralized and Decentralized Server Deployments

Advantages Disadvantages

Centralized Deployment

  • Easy coordination of backup and disaster recovery strategies.
  • Fast server-to-server communication in the central location.
  • Simplified server administration and system support.
  • The client/server communication over the WAN cannot be controlled or scheduled and may generate substantial transmission costs.
  • Increased demand for fault tolerance and redundant WAN links.
  • Decentralized Deployment

  • Client/server communication over the WAN can be avoided.
  • Faster server response times due to high net-available bandwidth in LANs.
  • Server-to-server communication over the WAN can be scheduled for hourly message transfer intervals or transfer during off-peak hours.
  • Users can continue to work with local resources if WAN connections are down.
  • Dial-on-demand WAN links of variable bandwidth can be used.
  • Administrative personnel required in each location
  • High administrative overhead.
  • High total cost of ownership (TCO), especially when placing servers in locations with few users or users who access e-mail infrequently.
  • Backup and disaster recovery strategies are difficult to coordinate.
  • The decision to deploy Exchange 2000 Server in a remote location is primarily driven by nontechnical reasons (see Figure B.5 in Appendix B). A local server in a LAN (high available bandwidth) provides optimal system response times to its messaging clients and gives the administrator wide-ranging control over the communication between the servers in the backbone. However, the number of users in the remote location must justify the costs for the separate server hardware and the resulting administrative overhead. If these costs outweigh the benefits, focus on a centralized deployment. Centralizing resources can lower your TCO, but you will also increase the remote location’s dependency on the central site. Bandwidth usage across the WAN will be higher because messages between users in a single location will need to travel across the WAN to the centralized Exchange server and then back across the WAN to the recipient’s client.

    Network Topology and Performance

    Unlike earlier versions of Exchange Server, Exchange 2000 does not utilize RPCs for its server-to-server communication. Instead, the new version always relies on e-mail messages transferred via SMTP or X.400, which tremendously improves the system’s flexibility. The core transport engine is the SMTP service, and SMTP and X.400 work well under any circumstances, even over dial-up connections of as little as 9600 bps (where RPCs are not supported). You can deploy Exchange 2000 Server literally everywhere in a TCP/IP-based network, but there are good reasons to concentrate all resources in a central location, as mentioned in the previous section and covered further in Chapter 5, "Designing a Basic Messaging Infrastructure with Microsoft Exchange 2000 Server."

    When you deploy Exchange 2000 Server centrally, several important questions arise (see Figure B.6 in Appendix B). For instance, you need to verify that the network infrastructure is not vulnerable to a single point of failure, such as a malfunctioning router. Backup lines are essential; otherwise, a single connectivity problem in the WAN may shut down all information services in a branch office. You also need to make sure that your WAN links provide sufficient bandwidth to handle the traffic generated by the messaging clients with acceptable performance. Keep in mind that your users do not only communicate with Exchange 2000 to create and read messages. They also have to contact a domain controller to successfully log on to the network, query DNS servers to retrieve IP address information, and communicate with a GC server to access server-based address lists and recipient information. Besides messaging, your users may also want to work with other resources over the network, such as a structured query language (SQL) database or a file server.

    Client/Server Communication over WAN Connections

    To find out whether your global network is capable of supporting a centralized server deployment, you need to quantify the average amount of traffic that must be transferred between the hub and the remote locations. This includes the workload introduced by messaging clients, such as Outlook 2000, as well as traffic originating from other applications. Unfortunately, however, there is no way to calculate exactly the amount of data your WAN will have to handle. One user may send or receive 10 messages per day, whereas another may receive 200 in the same time span, possibly containing attachments several megabytes in size. One user may download all messages from the server to the local workstation, whereas another may always work with his or her messages, appointments, contacts, and task items directly on the server. One user may use Outlook 2000, another may use Outlook Express, and yet another may use Outlook Web Access to access Exchange 2000 resources. If you plan to provide services for instant messaging, chat, or data and video conferencing or to begin to implement workgroup and workflow solutions, further traffic is generated, which again may differ from user to user.

    In short, there is only one way to reliably estimate the workload. You need to determine typical client configurations, such as an Outlook 2000 client downloading all messages from the server to a local personal store (.pst) file or an Outlook Web Access client accessing all information directly on the server, and then measure the client’s impact on the network for an average user in a test lab according to specific scenarios, such as logging on to the network, connecting to Exchange 2000 Server, browsing the network, sending messages with 1-MB attachments to a distribution group of 25 users, and so forth. Multiply the amount of client/server traffic by the number of workstations in the branch offices. Next, assess how long it takes to transfer the data across your WAN according to Table 3.3. If the outcome does not promise acceptable transmission times, you need to increase the available bandwidth by either upgrading the WAN links or reducing the amount of data that must be transferred. If this is not a possibility, you have to decentralize your server resources.

    Note


    Load Simulator from the Microsoft Exchange 2000 Server Resource Kit allows you to simulate numerous concurrent users sending and receiving messages and working with public folders. Your test results will help you determine the best client configuration for your branch office users.

    Table 3.3 Theoretical Transmission Rates

    Bandwidth In KB per Second

    56 Kbps (Modem)

    7

    64 Kbps (ISDN)

    8

    128 Kbps (Dual ISDN channels)

    16

    512 Kbps (Fractional T1)

    64

    1544 Mbps (T1)

    193

    16 Mbps (Token ring)

    2048

    100 Mbps (Ethernet)

    12,800

    46,320 Mbps (T3)

    5,928,960

    Even if your WAN connections promise sufficient bandwidth up front, you should verify your test results during the pilot phase to eliminate the risk that the performance tests did not reflect the actual behavior of your users in the production environment. Fully deploy the messaging client of your choice in a branch office and then use Windows 2000 Performance Monitor on the Exchange server to create detailed reports about effective transfer rates. Select the performance object called Network Interface and add the counters Bytes Sent/sec, Bytes Received/sec, and Bytes Total/sec to your chart. In addition, choose the counter Current Bandwidth to measure the current bandwidth in bps. You may also interview your pilot users to see whether they are satisfied with the performance of the Exchange 2000 organization. If your users are dissatisfied, you may have to change your deployment strategies before launching the production rollout.

    More Info: Exchange 2000 Bandwidth Requirements

    Microsoft assumes that Exchange 2000 users require the following bandwidth per mailbox:

    Criterion Bandwidth in Kbps

    Light mail user

    1.5

    Medium mail user

    2.5

    Heavy mail user

    4

    Minimum bandwidth recommended by Microsoft for client/server traffic

    56

    Based on these requirements, 10 heavy mail users in a location with a 64-Kbps WAN connection may be able to adequately access their mailboxes on a central server (10 users x 4 Kbps = 40 Kbps). A 64-Kbps WAN connection will not be suitable for a location with 50 users (50 x 1.5 = 75 Kbps minimum).

    Domain Name System

    DNS is an extremely critical network service without which the Exchange 2000 organization cannot function properly. DNS is required for Windows 2000 Server, Active Directory, Exchange 2000 Server, Outlook 2000, and Internet-based messaging clients, such as Outlook Web Access. It is important to note that your internal DNS systems must be able to handle service (SRV) records to fully support Active Directory. Windows 2000 Server publishes IP address information about Active Directory domain controllers via SRV records in DNS. Messaging clients will query DNS primarily to locate internal resources, such as GCs and Exchange 2000 servers. Exchange 2000 servers, in turn, rely on DNS to retrieve IP addresses of internal systems and also external mail hosts when connecting to the Internet.

    If you plan to connect your Exchange 2000 organization to the Internet, you need to verify with your DNS administration team that the Internet domain name of your organization is registered with the Internet Network Information Center (InterNIC) (see Figure B.7 in Appendix B). Your external DNS servers must contain mail exchanger (MX) Resource Records for your registered Internet domain, which must refer to your external mail hosts. Otherwise, foreign Internet systems cannot obtain the IP addresses of your public mail servers and consequently cannot transfer messages to your organization. Your external DNS servers and mail hosts should be located in the DMZ or at the site of your ISP. External DNS servers should not contain information about internal systems to avoid exposing internal information to the Internet. You can find detailed information about Microsoft DNS and the configuration of internal and external DNS servers in the Microsoft Windows 2000 Server Resource Kit.

    It is highly advisable to verify the DNS name resolution in all locations of your computer network (including the DMZ) because communication problems related to name resolution are very noticeable. For instance, nondelivery reports stating that recipients could not be reached due to unknown destinations are an indicator that your servers have trouble resolving Internet domain names. In Windows 2000, use the command-line utility NSLOOKUP.EXE to check the DNS name resolution. To find the IP address of a particular host, run NSLOOKUP.EXE, type its FQDN, and then press Enter. To find the mail exchangers of an Internet domain, type set type=mx , press Enter, type the Internet domain name, and then press Enter again. If everything works fine, Nslookup returns the corresponding MX records. Otherwise, ask your DNS administration team to correct the DNS configuration and then verify again.

    Lesson Summary

    The performance of your Exchange 2000 organization depends to a large degree on the reliability of your network infrastructure. Your LANs and WAN connections must be stable and backup lines must exist for critical links. Name resolution must work for any communication to happen and all systems must use the same network protocols. Exchange 2000 Server always requires TCP/IP and relies on DNS for name resolution. In mixed or heterogeneous environments, you also need to check the design of other services, such as WINS for NetBIOS name resolution or GSNW if you plan to integrate Exchange 2000 into a Novell NetWare-based environment. It is vital to review the existing computer network to make reliable design decisions for Exchange 2000 Server.

    Include graphical illustrations about the WAN and LAN topologies of your corporate network in your documentation. Each illustration should contain brief information about the sites of your organization, the number of servers and workstations in each of them, and the protocols and network services installed. Following these graphical representations, the network services in each LAN should be described in more detail. Your project team will need to know the configuration of Internet access points, DNS, WINS, DHCP, and components for interoperability with Novell NetWare, Apple Macintosh, or other systems. To decide whether to install Exchange 2000 Server on existing systems or purchase new machines, check the hardware, operating system, and installed applications of your servers and workstations. If possible, install Exchange 2000 on dedicated servers that do not run other main network applications, such as a SQL database. Make sure the names of new servers comply with the naming conventions in your organization.

    It is a good idea to review the existing environment for potential bottlenecks and shortcomings that may cause trouble during or after the production rollout. Shortcomings in the network infrastructure represent substantial risks, which you need to tackle in your risk management plan. For instance, if your DNS environment does not allow all messaging clients and servers to obtain valid IP address information, connection problems and nondeliverable messages will occur, which in turn will lead to serious end-user complaints. Server response times are likewise critical. The performance of your Exchange 2000 clients will suffer, for instance, if you force your users to connect to their home servers over WAN connections with insufficient bandwidth. If you cannot upgrade the WAN links and a significant portion of the messages are between people in a single office, you should deploy Exchange 2000 Server decentralized in each geographical location. A server locally deployed in a LAN can achieve optimal system response times and gives you wide-ranging control over the communication in the organization’s backbone.



    MCSE Microsoft Exchange 2000 Server Design and Deployment Training Kit(c) Exam 70-225
    MCSE Training Kit (Exam 70-225): Microsoft Exchange 2000 Server Design and Deployment (Pro-Certification)
    ISBN: 0735612579
    EAN: 2147483647
    Year: 2001
    Pages: 89

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net