Microsoft Exchange Server is part of the BackOffice suite of server products that runs on top of the Windows NT operating system. Windows NT is a 32-bit multithreaded, multitasking operating system. The Exchange Server can leverage this functionality by utilizing as many threads or application processes as needed to provide a robust messaging infrastructure.
You should now have an understanding of the core components and framework for the Microsoft Exchange server and client. This chapter helps you to understand the way Exchange integrates with the operating system. We will also discuss how Exchange can leverage the NT platform to provide a robust and fault-tolerant messaging solution.
In this chapter, you learn about the following:
The Core Functionality of Windows NT
Windows NT is a 32-bit operating system. It provides multitasking and multithreading capabilities. This means that the operating system can simultaneously process multiple requests or instances of an application.
NT is more that just an operating system. It is a framework to develop fault-tolerant client server applications. To enhance the operating system, NT provides a full set of Application Programming Interfaces (APIs) and Software Development Kits (SDKs). The operating system is more than a file and print server; it is an application server. Through the use of the APIs and SDKs, many applications can harness the power of the operating system.
The operating system runs on a variety of platforms including Intel, MIPS, Alpha, and the Power PC. This portable operating system has several key benefits. The following sections cover the benefits in detail.
NT provides native support for the following protocols: TCPIP, IPX, Netbeui, AppleTalk, DLC, SNA, X.25, and x.400(TP/x). This enables the operating system to support a wide array of clients. NT can communicate with Unix, Banyan Vines, DEC Pathworks, Netware, Apple Macintosh, and of course all of the Microsoft networking clients, including MS-DOS, Windows For Workgroups, Windows 95, and Windows NT Workstation.
This feature enables NT to interoperate in a heterogeneous environment. You will not be "trapped" by implementing the NT operating system into one of these environments. NT can offer additional functionality in these situations. The alternative means providing native support which would be very costly or impossible.
For example, NT can be easily added to a Novell Netware environment to provide Remote Networking or Dial-in access. The NT operating system ships with a complete remote access server component integrate with the OS. With Netware you would have to purchase an additional product known as "Netware Connect" to obtain this capability.
In the situation with Exchange, Netware clients can easily access an Exchange server running on NT with native IPX client software installed. Clients communicate with industry standards known as Remote Procedure Calls (RPC) using the Exchange server. NT supports every major communication protocol. Therefore, a client can connect to Exchange using RPCs over TCP/IP or IPX in a Netware environment.
For more information on this topic, please see Chapter 10, "Installing Exchange in a Netware Environment."
In addition, Microsoft will release a standard for Remote Procedure Calls (RPCs) over AppleTalk, the Macintosh's native communications protocol. In order for a Macintosh workstation to connect to an NT Exchange server, it will make RPCs over TCP/IP or AppleTalk. This functionality shows Microsoft’s firm commitment to a Macintosh operating system and recognizes that the Macintosh operating system has an important share in the marketplace (see fig. 4.1).
NT supports most industry standard network protocols.
Security is a key element of any messaging system. Users want to know that their message will get to its destination without someone intercepting it. Exchange expands upon the Class C2 Level of Security which is at the heart of the NT operating system. The Department of Defense defines this level of security.
Class C2 requires a secure logon, discretionary access control, and full auditing capabilities. The secure logon requires that users identify themselves with a unique logon identifier (user ID) and password. This logon must be validated prior to accessing any system resources.
The discretionary access control enables the owner of a resource, whether it is a file, sub-directory, or printer, to determine who can access the resource. This also defines the level of control the user has over the resource. The owner grants rights to a user or group of users.
Auditing is the capability to log the security information of each operating system transaction to a file based on user ID. This feature provides the capability to detect and record important security-related events or instances in which security was challenged.
C2 security has several other components to its matrix of functionality. However, the Exchange server leverages its core features. Not all aspects of C2 security are required for use with Exchange. You also do not have to use every feature of C2 security when working on or creating a network application operating system. The company using the C2 security system can determine the level of security required.
NT provides several tools to assist in managing the network as well as the operating system. NT includes the Server Manager, the Event Viewer, and the User Manager to manage processes, define security privileges, provide auditing and security logging, and to create new users and groups respectively.
The Server Manger (see fig. 4.2) enables the administrator to view all of the servers from a single domain, multiple domains across the enterprise, or individual servers and workstations inside a domain. The functions that are available enable you to control the share or access points to the file systems of a server, and to stop and start application processes. Using these functions, you can also close user sessions and manage specialized access via AppleTalk, Netware Gateways, and the File Transfer Protocol (FTP).
Windows NT Server Manager enables remote management of the network servers.
The event viewer, also known as the event log, is the centralized repository for system, application, and security information for a server or workstation. From a remote console an administrator can pull up the event viewer to see the entries of a network server. All Backoffice certified application must write the events to the event viewer. Events can be informational (blue), cautionary (yellow) and serious (red) in nature. You will be able to tell whether your tape backup has finished properly and at what time of day it completed. From the system, you will see whether there have been any problems related to the operating system and the hardware. From the security log, you can view all of the information predetermined for auditing.
The event will store information related to the Exchange server and all of its gateways, connectors and external processes. It will also store security information (see fig. 4.3). Exchange itself has a security log which extends the basic functionality provided by the event log.
Windows NT Event Viewer records systems, security, and application events from the operating system.
The User Manager is a tool used by the security administrators or domain administrators to create the single domain logon user ID. This ID includes all of the user's application profiles, group memberships profile, and time and workstation restrictions. The User Manger helps you to define trust relationships among domains, define auditing functionality, and general domain user account functions.
From the User Menu, you can select to create a new user, a local group, or a global group. The user ID is the individual ID used in conjunction with the password to be authenticated by the domain to access network resources. Local groups are those residing within the single domain in which it was created. If the domain is referred to as "Boston", all local groups created in this domain will only be able to access resources within the domain. Global groups, however, can be used to provide access to trusted domains. A local group can contain local user IDs, as well as global groups from both the local and trusted domains.
Exchange adds the functionality of creating a mailbox for users at the same time as assigning their domain logon ID (see fig. 4.4). This gives the mail, security, and domain administrators control over the same set of user accounts. In large organizations, this is the responsibility of a Network Security Group. This one group would be responsible for creating the user IDs as well as the appropriate mailboxes.
Windows NT User Manager enables you to create domain user IDs, including the Exchange mailbox.
The functionality provided by these three tools is built into the NT operating system. These tools can be run on remote machines, 16-bit workstations, and from the Internet.
Introduction to the Windows NT Domain Architecture
At the heart of the Windows NT network operating system is the fundamental architecture of the Domain Model. A domain is a logical grouping of servers and workstations. One server must be the "Primary Domain Controller" (PDC) and subsequently have "Backup Domain Controllers" (BDCs). NT provides the capability to build servers as "name servers" which belong to the domain. These servers, however, are not responsible for replicating user account and security information throughout the domain. The PDC and BDCs remain synchronized by updating each other’s user and security databases at regular intervals 24 hours a day, seven days a week.
The domain architecture consists initially of a single PDC of a single domain. From there, NT architecture can grow in any number of combinations that can include multiple BDCs in a single domain or a number of trusted domains with BDCs and member servers.
Trust relationships can be created between multiple domains. Trusts enable users from one domain to be granted secure access to resources in a second domain. This maintains the concept of the single network logon. Users will see no change from a single domain to multiple domains.
Two types of trusts exist: one-way and two-way. One-way trusts are set up to enable users from the second, or "trusted" domain to access resources of the first domain. The second domain, however, has the freedom to create its user accounts and manage its own domain independently of the first domain. This can be illustrated using a distributed administration model in which certain divisions have their own network administration; however, there is a central domain providing corporate-wide resources. The divisional domains can completely administer their own domains without affecting the central domain. The central domain has the capability to enable the divisional domain to access the central resources. This is useful because full administrator privileges can be given out at the divisional level without administrative rights over the entire WAN.
Two-way trusts grant access and administrative functionality between all domains that are in them. This is also known as the Complete Trust Domain Model (see fig. 4.5).
Establishing trust relationships between domains enables one domain to access the resources of another.
A domain is a logical grouping of servers that share the same user accounts database and provide a single logon for all users to all the servers in the domain. As a comparison, on Novell Version 3.x networks, each server maintains its own user account database or "bindery". In this way, user accounts must be individually created on each server.
The concept of a domain is primarily used for centralized administration. All the servers in a domain are updated with a single action. Regardless of when the user ID is created or modified, all the servers maintain the single logon for the group of servers in the domain.
A single domain only consists of a PDC. For small organizations, additional BDCs can be added to validate user access rights. In the single domain, there are no trust relationships. Small organizations primarily use the single domainThese organizations do not have to be interconnected with other domains. Sometimes corporations use a single domain as a development domain. In this way, they do not affect the production domain. The server in the single domain can communicate with the other domains; however, additional user IDs will be necessary (see fig. 4.6).
Single Domain Model represents the simplest form of a Microsoft Windows NT network.
In an environment with multiple domains, you can create trust relationships between domains. As discussed previously, domains can be interconnected via one-way or two-way trust relationships. In the master domain model, there is a one-way trust between the divisional domains and the central domain. All users and global domain groups are defined in the master domain. All other domains trust the master domain. This model ensures centralized administration for all domains. Again, this model maintains the single network logon by establishing one user account for the enterprise.
For example, in a large organization, the MIS Division manages from a central point. Therefore, the same should hold with the domain architecture. From one location, all users and security are maintained. The master domain referred to as "Corporate" houses all users and global groups. The resource domains, "Sales," "Marketing," and "Legal," only maintain local groups. When a resource is needed from the Sales domain, a local group is created in Sales, and its members include a global domain group from Corporate.
One disadvantage to this model is that performance might decrease as the number of users and groups grows. For this reason, larger domains need to consider the next model (see fig. 4.7).
The Master Domain Model puts global groups and users in the master domain. This Model also places resources in separate domains.
The multiple master domain extends the single master domain into a broader scope. This domain model is typically seen in very large organizations. If your organization has two major corporate headquarters, and many divisions, you might choose to implement the multiple master domain model.
Building on the previous example, the multiple master domain model has two tiers of domains (see fig. 4.8). The first tier interconnects the master domains. "Corporate" and "International" are the two domains. These two domains each house their respective users and global groups. These domains are then configured with a two-way trust. These domains trust each other. Therefore, only one copy of each user ID is needed.
The second tier of domains includes all of the resource domains. These domains each maintain a one-way trust to the two master domains. This model can be scaled to networks with any number of users. You can easily have upwards of 10,000 users supported with this model. The resource domains can then be grouped logically based on function and geographic location. The resource domains also provide for local administration at the divisional level. The disadvantage to this model is that there are more trust relationships to manage. Also, not all user accounts are located in one domain.
Multiple Master Domain Model provides the scalability needed in a large organization when the Master Domain Model is not sufficient.
The final option available for an NT domain model is the Complete Trust. This model is best used in companies in which management of users and groups is distributed among different departments. Rather than being centralized, this model extends the administration down to the divisional level. Every domain trusts every other domain on the network. One immediate disadvantage to this model is that an administrator of one domain now has full rights over every other domain in the model. This can lead to security problems. If you are going to use this model, an auditing process could help manage who has made administrative changes on the various domains.
In this model (see fig. 4.9), the resources and the user accounts are grouped into divisions. Again, the only situation in which a Complete Trust is appropriate is when there is a lack of centralized management. This model is not practical for corporations with a large central department. The reason is that the model lacks the security needed for a large enterprise network.
The Complete Trust Domain Model is intended for decentralized management and carries many security risks for an enterprise network.
Several options exist for an NT domain model. In Chapter 5, you are given the criteria for selecting which domain architecture to use when planning to deploy Exchange in your environment.
Microsoft also provides a tool through its BBS and Internet site to assist with planning a domain architecture. This tool is referred to as the "Domain Planner." It is a Visual Basic application that steps you through the options when choosing your domain and trust relationships.
Understanding Exchange and NT Operating System Integration
This section explains how Exchange leverages the NT operating system. Exchange has been created to exploit all the features of Windows NT Server, including all the tools. These tools include the single logon, permissions that can be user defined, the User Manager for Domains, the Event Logger, and the Performance Monitor.
Exchange sits on top of the NT OS. However, it has hooks into the OS to provide a robust, high performance messaging system. Not all of the NT terminology applies or directly converts to Exchange terminology. The reason is that the messaging platform has its own architecture.
Exchange uses the concepts of Organizations and Sites, whereas NT uses domains. Organizations are at the top of the Exchange hierarchy. Typically, you find only one Organization name in the entire enterprise. Sites, on the other hand, can be geographic locations, divisions, or functional areas. Sites can also map one to one with domains.
Sites can span across multiple domains, provided that the domains are trusted. This is necessary because a server within a site must authenticate each user.
Both the NT domain model and the Exchange architecture use the term "server." Within NT, a server can be a PDC, a BDC, or a domain member server. Within Exchange, servers exist within a site. It is not necessary for the Exchange server to be either the PDC or a BDC of a domain. For performance reasons, it would be best for the Exchange server to simply be a member server. This way, the Exchange servers share the resources of a domain without having to continually replicate security information or validate user accesses to the network.
Here is a list of Exchange’s features that help the Exchange server to closely integrate with the NT Server.
The NT Service Manager enables you to start, stop, and pause services, as well as control their start-up properties.
Exchange extends the functionality of the Performance Monitor bundled within NT. This extensive monitoring tool enables you to observe both processor and disk space utilization, memory allocation, page faults, and over a thousand more counters.
Exchange adds some specific counters to the performance monitor which enable the administrator to view statistics of critical elements of the Exchange processes. These include the number of open tables on the message store, cache hits, I/O performance on reads and writes, RPC packets per second, number of bytes sent and received, and more.
Exchange NT Dependencies
Exchange relies on the NT operating system for certain functionality. The major function is that you must create a user account in the operating system for Exchange to run its services. Exchange also can import and export names from the NT domain user database. This facilitates a quick migration to Exchange from your existing NT Network architecture.
Exchange relies on the connectivity that NT provides. Exchange enables all types of clients to connect to its servers. Novell Netware clients, Macintosh, Unix, and all the Windows clients can connect to Exchange using their native protocols. This is made possible through NT’s use of RPCs and multiple protocol support.
For remote access solutions, Exchange again relies on the NT OS. NT has an integrated remote access server as part of the operating system. The NT server running Exchange can be configured for a user to dial directly into the server and access Exchange, as well as any other network resources. For performance reasons, it might be more appropriate to set up the remote access server on a dedicated server.
For WAN connections, NT supports x.25 and ISDN without any additional software. An Exchange server can be configured to use an x.25 or ISDN connection to bridge the message route. If WAN links are already in place, these dial-up solutions provide a second level of fault-tolerance and an additional message route, in the event of an emergency.
The system service account enables Exchange servers to authenticate each other when transferring messages, updating the global address list, or performing directory synchronization. This account must be created with certain specifications.
It is important to carefully plan the implementation of this account. You must have a domain model that supports these user accounts. Whether you have trusted or untrusted domain, you must ensure that the Exchange services can be authenticated between servers. If this does not occur, mail will not be forwarded from one system to another.
Exchange relies on the C2 level security of the operating system. Any user who attempts to access the system must first be authenticated by the domain. Exchange extends the single logon ID. Therefore, the domain logon also validates users for accessing their Exchange mailbox. As mentioned previously, in the file-sharing mail systems, users had full access to the file system that comprised the post office. Exchange now manages the access to the post office based on the central domain user database.
Exchange itself provides three levels of security. The user accounts are leveraged from the NT user database. From within the Exchange Administrator Program, a user account can be specified as a complete administrator, a local administrator, or as a read- only administrator.
For a detailed discussion on Exchange security, see Chapter 23, "Exchange Maintenance."
There are many issues related to using Exchange on the NT operating system. NT provides connectivity to almost any other operating system used in the enterprise. NT should not be a point of concern when deploying Exchange. The NT OS interoperates more easily with your existing network operating systems and mail environments than some proprietary systems that communicate with themselves. This is the case with PROFS or OfficeVision. Exchange leverages the NT OS to provide a strong messaging backbone.
In this chapter, you learned how Exchange integrates with the NT operating system. For more information, see the following chapter:
Previous Chapter <-- Table of Contents --> Next Chapter
QUE Home Page
For technical support for our books and software contact firstname.lastname@example.org
Copyright ©1996, Que Corporation