Thanks, readers, for your warm response to this column. You suggested several of this month's questions. I welcome your feedback, questions, and requests for topics.
I want to use Exchange Server to sign and encrypt email messages. How does Exchange support these security features?
The Advanced Security feature lets Exchange users encrypt and sign messages. Message signing verifies the identity of a message sender and ensures that no one has modified the content of the message. Message sealing provides confidentiality by letting a sender encrypt the body of a message and any attachments. The basis of these features is the International Telecommunications Union (ITU) X.509 standard for public key and private key technology. A public key is a key that a certificate authority makes available to the public and that you can use to seal and verify messages. A private key is a key that only the individual user knows. The Exchange or Outlook client stores a private key in a local secure file (.epf), and you use it to unseal and sign messages.
In Exchange Server 4.0, 5.0, and 5.5 (before Service Pack 1—SP1), the Key Management (KM) Server implements and manages public and private keys. The KM Server is an X.509 certificate authority responsible for maintaining key pairs and certificates. In the initial release of Exchange Server 5.5, the KM Server is the certificate authority.
In Exchange Server 5.5 SP1, Microsoft uses its Certificate Server instead of the KM Server for complete Advanced Security functionality (for more information, see Tony Redmond, "Exchange Server 5.5 Service Pack 1," Windows NT Magazine, July 1998). Certificate Server provides a more open and interoperable solution for Exchange Server Advanced Security. In Certificate Server, Microsoft has based security concepts on Internet protocols instead of embedding them in Microsoft's proprietary implementations.
What are the server-side components of Exchange Server Advanced Security?
On the Exchange server side, the KM components can reside on any server in an Exchange Server organization. You can have only one KM Server per organization. Microsoft has integrated the components with Exchange Server and implemented them as a Windows NT service—the KM Service. A KM administrator (who is often the same person as the Exchange Server administrator) administers the KM Server, which functions as a certificate authority in the Exchange environment. Table 1 lists the Exchange Server Advanced Security's server functions.
What are Exchange Server Advanced Security's client-side components?
From the client's point of view, Advanced Security appears much simpler. The Exchange or Outlook client requires only that you enable the Advanced Security feature via a security DLL (ETEXCH.DLL). The client security DLL, the System Attendant, and the KM Server generate users' public and private signing key pairs. When you have set up Advanced Security, security information will reside in four locations: the Directory Store (DIR.EDB), a Client Security File (.epf), the KM Database (KMSMDB.EDB—beginning with Exchange Server 5.5), and an X.509 Certificate that the KM Server maintains. Table 2, page 14, shows how Exchange allocates the information among the four locations.
What steps does the administrator take to set up Advanced Security?
From the User Mailbox Properties dialog box, select the Security tab and, at the prompt, type in the KM Server Administrative password to display the Security Properties page. Select Enable Advanced Security. The Security Administration DLL will then retrieve the KM Server location and display the Encryption Properties page. The KM Server uses the Encryption properties information to create a sealing key pair and an 8-character security token. The Security Administration DLL decrypts the security token and displays the results for the KM administrator to distribute securely to users for use in the second phase of the process. (In Exchange Server 5.5 SP1, Certificate Server performs the KM Server tasks.)
What steps does the user follow to set up Advanced Security?
The user receives the decrypted security token through a secure mechanism. Standardization of the user key distribution process ensures Advanced Security integrity.
- From the Options dialog box, the user selects the Security properties page to enable Advanced Security on the Exchange or Outlook client. Note that this process will vary slightly, depending on which client (Exchange or Outlook) and version you're using.
- The user selects Setup Advanced Security (or in Outlook 98, Change Security Settings). The program prompts the user for the 8-character token, the Security file name (by default, MAILBOXNAME.EPF), and a password to secure the keys.
- The client program sends a request to the KM Server to generate the public and private signing keys; the request is in a message to the System Attendant's mailbox on the Exchange Server, where the KM Server resides. The System Attendant notifies the user when it has processed the request.
- The KM Server generates signing and sealing certificates and sends a mail message to the user with the following enclosed:
- X.509 sealing certificate
- X.509 signing certificate
- Certificate authority's certificate
- User's private sealing key
- When the user receives the message with the certificates and keys, the client program prompts the user for the password entered to secure his keys. This password validates that the user receiving the message was the original sender of the request for Advanced Security services.
- The client Security DLL extracts the public sealing certificate and sends it to the Exchange Directory Service for storage in the directory to use for sealing messages for this user.
- The Advanced Security feature in the client program stores the private signing key, the signing and sealing certificates, and the certificate authority's certificate in the user's local security file (.epf).
I need to determine the requirements for the bridgehead servers in my Exchange Server deployment. What are some important considerations?
An Exchange environment has two kinds of servers: servers that directly support users (e.g., mail and public folder servers) and servers that perform background functions (e.g., routing and replication, distribution list expansion, and Free/Busy services). A bridgehead server falls into the second category.
A bridgehead, or connectivity, server communicates with other sites or foreign systems by running one or many messaging connectors. Administrators usually deploy bridgehead servers as a single point of connection between sites or foreign systems. For example, suppose a company has a headquarters location in Seattle and a division office in New York. Each location is a separate Exchange site, and a WAN connects the sites. At each location, the company can place a bridgehead server dedicated to routing and replication activities between the two sites. These connectivity servers serve as a dedicated path for message activities between the company's Seattle and New York locations. Bridgehead servers offload the connectivity functions to dedicated servers and simplify administration or increase mail server performance.
Bridgehead servers primarily run messaging connectors such as the Site Connector, X.400 Connector, the Internet Mail Service (IMS), and the Dynamic Remote Access Service (RAS) Connector. Connectors increase the load on an Exchange server because a bridgehead server does routing and selection. Routing is the process of determining which messaging connectors are available to deliver or route a message; selection is the process of choosing which connector to use, based on availability and configured connector costs. Combined with the overhead of message delivery, routing and selection is usually processor-intensive and, to a lesser extent, memory-intensive in nature. Therefore, bridgehead servers usually require more processor and memory resources than a typical mail server in the Exchange environment requires.
Specific recommendations for Exchange bridgehead server configurations vary with the installation, but here are some tips:
- Bridgehead servers and the functions they perform most often result in higher processor and memory resource utilization.
- In bridgehead servers, server response time isn't as important as throughput and messages per second.
- The number of routes and connectors and the type of connector running on bridgehead servers require more resources.
- Intersite routing and replication traffic levels directly affect bridgehead server resource use.
- Non-Exchange topology such as WAN architecture, link speed, name resolution (Domain Name System—DNS—and Windows Internet Naming Service—WINS), and security authentication (NT domains architecture) affect bridgehead server performance, efficiency, and reliability.
Several Exchange deployments I've seen start with the mail server configuration and add a processor and 128MB of RAM. Although this configuration might not work for all Exchange deployments, you can use it as a starting point. Whichever bridgehead server configuration you select, apply standard performance-management and capacity-planning methods to help you tune your bridgehead server configuration.
I want to establish performance baseline standards for my Exchange servers. What do I need to consider when I'm monitoring performance and determining Exchange Server health?
Several principles can guide performance monitoring. One key concept is the difference between response time and throughput. Users measure server performance in terms of response time—how long do you have to wait after doubling-clicking on a mail message until the message opens for reading? If a server is heavily loaded and has constrained resources, this response time is longer—a direct correlation between server resource bandwidth and server load. Response time is an important measurement for servers that directly support user functions (e.g., mail, scheduling, and public folder applications), but it is less important for servers performing background activities (e.g., message routing and replication). For example, in a bridgehead server environment, throughput measurements such as messages per second or bytes per second are more relevant performance measures than response time.
You also need to understand what bottlenecks are. Bottlenecks occur in server subsystems such as processor, memory, and disk and are the resource subsystem with the highest demand. Bottlenecks often are closely interrelated because the presence of one only masks the resource with the next highest demand. In addition, a bottleneck in one resource might prevent Exchange from fully using another resource. For example, a disk subsystem that is beyond its capacity will delay the processor subsystem from completing tasks. The result is low processor utilization while the processor waits for disk I/O to finish.
When you use a tool such as Performance Monitor, you need to set appropriate intervals for the frequency and duration of the monitoring period. If you choose the wrong intervals, you might miss valuable information. For example, when you're logging or graphing performance data for a disk subsystem such as Disk Queue Length or Reads/sec., your update interval time periods can fail to present an accurate picture of disk subsystem performance. With a 30-second capture interval, the data might appear to be well within subsystem capacities (e.g., Disk Queue Length is less than 2 I/Os). However, if every 5 seconds the subsystem is experiencing spikes in disk utilization—because of the load or phenomena such as the write-back cache flushing algorithm—you might miss these peaks and misinterpret the load on the disk subsystem.
Another consideration is the scale you use when you analyze server performance data. One guideline is to view performance data (counters) with similar data. For example, viewing processor utilization (measured as a percentage) with system memory data (measured in bytes) could confuse you.
Many objects and counters can provide important data for characterizing your server's function and load. Table 3 lists the most commonly used performance indicators that can provide a summary view of Exchange Server's health. For more information on optimizing performance, consult the Exchange Server Administrator's Guide. The Exchange Server Administrator installation also includes a set of Performance Monitor files.
