- Preparing for Implementation of Exchange 2003
- Preparing to Install Exchange 2003
- Conducting Preinstallation Checks on Exchange 2003
- Performing an Interactive Installation of Exchange Server 2003
- Performing a Scripted Installation of Exchange Server 2003
- Completing the Installation of Exchange 2003
- Performing Postinstallation Configurations
- Configuring Additional Server Services
- Testing the Exchange 2003 Installation
- Summary
- Best Practices
This chapter is from the book
This chapter is from the book
This chapter is from the book
Configuring Additional Server Services
In addition to basic Exchange servers that host mailboxes for user email accounts, there are other Exchange Server 2003 services that can be configured:
Bridgehead servers
Front-end servers
Public folder servers
SMTP mail routing servers
Installing a Bridgehead Server
A bridgehead server is a routing server that accepts mail from another server and then distributes the mail to the next server in the route. Similar to the hub-and-spoke system used by airlines to prevent having to fly nonstop flights to and from every single city around the world, the bridgehead server minimizes the site-to-site direct-traffic flow by focusing mail between bridgehead servers.
Many times administrators with high-speed WAN bandwidth question why they wouldn’t just have all Exchange servers route mail directly to all other Exchange servers. An example gives the best explanation: If a manager in the United States sends a message with a 20MB attachment to managers in 10 different European offices, 200MB of mail is routed between continents. However, if the organization had a bridgehead server in the U.K., only one 20MB message, with attachment, would go between the U.S. and the U.K. Then the message would be distributed from the U.K. to the rest of the European sites. Even between local sites with a T1 line, the belief is that there is plenty of bandwidth between the sites and users can send any size email because it’s a local office. So unless attachment restrictions are placed on servers, a user could send a 40MB attachment to dozens of offices, taking up hundreds of megabytes of bandwidth. A bridgehead server can consolidate bandwidth between an East Coast and West Coast connection, minimizing traffic across the country.
To configure a bridgehead server, from the Remote Bridgehead tab on the routing group connector Properties page, a target server can be specified that will receive messages in the destination routing group. Multiple servers can be specified, and connections to the server are attempted in the order of the servers listed in the remote bridgehead list.
The Delivery Restrictions, Content Restrictions, and Delivery Options tabs are used to control which users can send messages and of what type across the connection. The Delivery Options tab includes the option of scheduling large messages across a specific message route during a specific period of time. For example, large attachments from one site to another site that has a slow connection can schedule all attachments of a certain size to be transported later in the day or evening. Using this option for messages greater than a few megabytes on busy or slow links can keep mail flowing without clogging the link.
When the connector is configured, the administrator is then prompted to create a corresponding connector in the remote routing group. The administrator should keep this in mind when naming the connector, because automatically configured connectors in the remote routing group will use the same name as the connector configured in the local routing group.
Routing group connectors are not the only option for administrators to link routing groups. The SMTP and X.400 connectors also can be used for linking. Both connectors have a Connected Routing Groups tab that can be used to connect routing groups when bandwidth is limited or other services, such as encryption, are required.
Enabling SSL for Services on Front-End Servers
You can enable most of the protocols on the front-end server from within the Exchange System Manager. To enable SSL for POP3, IMAP4, SMTP, and NNTP, use the following steps:
Open Exchange System Manager.
Navigate to Administrative Groups, Servers, Protocols.
Select a protocol and expand it.
Right-click on the protocol and choose Properties.
Click on the Access tab.
Under Secure Communications, click on Certificate.
Select Next.
Select Create a New Certificate and click Next.
If you have an internal Certificate Authority (CA), you can choose Send the Request Immediately to a CA; otherwise, choose Prepare Now and Send Later, and then click Next.
Type a name for the certificate, choose the bit length, and click Next.
Type the organization name and unit and then click Next.
Type a common name for the Web site or fully qualified DNS name.
Type the country, state, and city, and then click Next. (Do not use abbreviations.)
Type a path and filename for the CSR file and click Next.
Review the summary and click Next.
Click Finish.
If your organization uses a third-party certificate authority such as Verisign, Tharte, or others, send the CSR file created in the previous steps to the third-party certificate authority to have a valid certificate file created. After a certified file is issued by the third-party CA, do the following:
Open Exchange System Manager.
Navigate to Administrative Groups, Servers, Protocols.
Select a protocol and expand it.
Right-click on the protocol and choose Properties.
Click on the Access tab.
Under Secure Communications, click on Certificate, and then click Next.
Choose Process the Pending Request and Install the Certificate, and then click Next.
Click and browse to select the certificate file you received from the third-party CA, and click Next.
Review the summary of the certificate to verify that it is correct and click Next.
Click Next on the confirmation screen.
Managing Public Folders
Public folders are collaboration objects in Microsoft Exchange that can be used to share information with a group of individuals in the organization, and are the basis of workflow applications.
Public folders can be created either through the Outlook 2003, Outlook XP, or Outlook 2000 client or through Exchange System Manager. To create folders through the Exchange System Manager, locate the folders container in the administrative group. Right-click the default public folder tree and select New, Public Folder. The tabs, shown in Figure 3.12, are for the following:
General—Contains the option of configuring an address list display name to be different from the folder name and whether folder content read and unread information is tracked for each user.
Replication—Controls which public folder stores receive a copy of the folder and at what frequency the information is replicated.
Limits—Configures the storage, deletion, and age limit settings. These settings can be inherited from the public store database settings or from a public store system policy.
Details—Allows for the entry of administrative notes.
)
FIGURE 3.12 Tab options when creating a public folder.
To mail-enable the folder, right-click the folder in Exchange System Manager and select Mail Enable. After the folder is mail-enabled, right-click the folder and select Properties to view the following tabs:
Exchange General—Displays the folder’s alias and the public folder tree that contains the folder. Options also exist for Delivery Restrictions and Delivery Options, which are inherited from the Exchange organization.
Email Addresses—Lists email addresses for the object, which are defined in the Recipient Policies from Exchange System Manager. This includes the SMTP, X.400 address, and addresses for other mail platforms.
Exchange Advanced—Includes settings that control address list visibility and the custom attributes.
Folders can also be created in Outlook 2003, Outlook XP, or Outlook 2000 by accessing the Public Folders, All Public Folders container.
Creating New Public Folder Trees
MAPI clients can use only the default public folder tree, so this process does not apply to organizations that use only the Outlook 2003, Outlook XP, or Outlook 2000 client. Only Web-based clients can use other public folder trees. Organizations might want to consider creating a new public folder tree to support customized Web-based applications that use the Web store capabilities of the public store. Creating new public folder trees is a four-step process:
Create the tree.
Create a public store associated with the tree.
Link the tree with the public store by using the Associated Public Store dialog box when creating the store.
Mount the public store.
To create new public folder trees, use Exchange System Manager to locate the folders container in the administrative group. Right-click the folders container and select New, Public Folder Tree; enter the name of the folder tree. The second step is to create a public folder store by right-clicking a storage group and selecting New, Public Store. The third step is to use the Browse button to select the new public folder tree as the associated public folder tree when creating the public store. The final step is to mount the store. To mount the store, choose Yes when prompted to mount the store.
Using Dedicated Public Folder Servers
Many Exchange 5.5 organizations used dedicated public folder servers to support their folder installations and keep the load of collaboration applications and repositories off their mail servers. This is still an acceptable practice; however, do not remove the private store from the dedicated public folder server if the organization plans to administer the public folder tree on the server from Exchange System Manager. To configure dedicated public folder servers, leave the mailbox store unpopulated or permanently dismount the mailbox store by marking the store with the Do Not Mount This Store at Start-up option on the Database tab of the mailbox store.
Designing Public Folder Trees
The first level of the public folder tree is called top-level public folders. In most organizations, the top few levels of the public folder structure are designed with some hierarchy in mind. This is done to organize the information and also to control the replication of information across the network. It might not be efficient to replicate the entire public folder tree to every server in the organization if the information is needed in only certain areas of the company. Generally, the first few levels are designed with a department or geographic organization. Most Exchange administrators usually lock down the top-level folders to prevent the hierarchy from being corrupted by users. To lock down the top-level folders, set the following permissions:
Right-click the Public Folder tree under the folders container in the administrative group and select properties.
Click the Security tab.
Select the Everyone group.
Select the Deny option for the Create Top Level Public Folder permissions.
Understanding Public Folder Replication
Public folder replication enables information that’s created in one folder to be replicated to all other public stores configured on its Replication tab. Public folders operate in a multimaster replication hierarchy where every public store has a read and write copy of the folder. By default, a public folder inherits the replication schedule from the public store Replication tab or the public store system policy that is applied to the server.
Plan on spending some time developing the replication scheme for the public folder hierarchy. Not all information in the tree needs to replicate immediately. Exchange administrators should make sure that top-level folder administrators understand which folders replicate more quickly than others and should be used for time-sensitive information.
System Folders
The Exchange system folders control many of the underlying components of the Exchange organization, such as storing the Offline Address Book and the public free and busy time information that users see when they create meeting requests. The Exchange system folders include EForms Registry, Events Root, Nntp Control Folder, Offline Address Book, Schedule+ Free Busy, StoreEvents, and System Configuration. Administrators might need to view information about the system folders when troubleshooting problems on the server. By default, the system folders are not displayed in Exchange System Manager. To view system folders, follow these steps:
Open Exchange System Manager.
In Exchange System Manager, expand the Folders container.
Right-click Public Folders.
Select View System Folders.
SMTP Connectors and Virtual Servers
SMTP is the primary message routing protocol used in Exchange 2003 and is the backbone of many other services, such as OWA, POP3, and IMAP. Exchange 2003 uses the base SMTP service configuration provided by IIS and extends its functionality to link state routing, advanced queuing engine, and enhanced message categorization. Many of the features that are added to the base SMTP service are Exchange-specific commands.
Two basic components need to be configured for SMTP on the Exchange 2003 server: the SMTP Virtual Server and the SMTP Connector. The SMTP Virtual Server is used to define settings—such as the domain and authentication—for connections. Multiple SMTP virtual servers can be used on a physical server to support the needs of different groups in the organization. The purpose of the SMTP connector is to use SMTP to route external mail. The SMTP Connector is the replacement for the Internet Mail Service in Exchange 5.5. The connector defines how that mail is delivered and any restrictions on messages or connectivity that apply to the delivery.
Creating SMTP Connectors
The following process assumes the connector is being installed to send messages to the Internet.
To install the SMTP connector, right-click the routing group’s connectors container and select New, SMTP Connector. To configure the connector, use the following steps:
On the General tab enter a descriptive name for the connector, such as SMTP(Internet).
Select the method to deliver the SMTP messages, either DNS or smart host. If you’re using a smart host, it’s better to use a hostname rather than an IP address; an IP address change in the organization will not cause mail routing to fail as long as DNS properly resolves the name to another IP address. If you’re using IP addresses, they must be enclosed in brackets ([]). Multiple smart hosts can be entered but must be separated by semicolons (;) or commas (,).
Add a server in the local routing group as the local bridgehead. This will be the server responsible for delivering SMTP messages in this routing group.
Add an address space entry. If this connector will route all mail to the Internet, create an SMTP address entry and leave the default setting to send all addresses. If there are multiple connectors with the same address space entry, the cost can be modified to set one of the connectors to a higher or lower priority. The higher the cost, the lower the priority.
Set Connector Scope for Entire Organization or the routing group. If using Entire Organization, all servers in the organization can send messages through this connector.
Set the advanced settings for security if necessary. For sending mail to servers on the Internet, set the option for HELO instead of EHLO for ensured interoperability.
The General tab of the SMTP connector is configured to deliver SMTP mail to the Internet. The other tabs on the SMTP connector can be configured as needed, but most organizations leave the settings as the default when configuring connectors to send SMTP mail to the Internet.
Creating SMTP Virtual Servers
In most Exchange organizations, it’s not necessary to create additional SMTP virtual servers. Unless the organization is supporting multiple domain names that require different settings or POP3 and IMAP users that require secured SMTP relays, creating additional SMTP virtual servers is not necessary.
To create a new SMTP Virtual Server, right-click the SMTP protocol container and select New, SMTP Virtual Server. The wizard then prompts for the name of the virtual server and the IP address. It’s best to use a descriptive name for the virtual server, such as the domain name (in this example, smtp.companyabc.com). Only IP addresses that have been configured on the server’s LAN adapters appear in the IP address selection box.
The following tabs are available for the SMTP Virtual Server:
General—The General tab can be used to limit the number of connections and the connection timeout and contains the IP address and port number combinations configured for the virtual server. When you’re adding additional IP addresses, the Enable Filter option can be used to apply message filters that have been configured in the Message Delivery options under the Global container for the organization. Logging for the SMTP connection can also be enabled here.
Access—The Access tab controls the Authentication mechanism in place and can be used to enable secure communication under the Certificate and Communication buttons. Connections and SMTP message relaying can also be controlled.
Messages—The Messages tab controls the number of messages that can be transferred and the handling of nondelivery reports. A setting that’s really helpful during mail migrations is the Forward All Mail with Unresolved Recipients to Host option, which enables mail for the same domain name to be delivered to another mail platform that may have been previously responsible for the SMTP domain name for the Exchange organization.
Delivery—The Delivery tab configures outbound message retry intervals, authentication, DNS, and smart host configuration information.
Securing SMTP Mail Relays
The Relay button on the Access tab of the SMTP Virtual Server is responsible for controlling the capability for remote hosts of relaying SMTP messages off the Exchange SMTP server. Open SMTP mail relays are a target for spammers, who use the open relay to send unsolicited email messages anonymously.
By default, SMTP message relaying is not enabled. Only the hosts specifically entered in the relay configuration can relay SMTP messages. By selecting the option All Except the List Below, you open the relay to any server on the Internet. The check box Allow All Computers Which Successfully Authenticate to Relay is an override for the lists of hosts listed above the check box that are either allowed or not allowed to relay. This check box is selected by default and will allow POP3 and IMAP clients to relay SMTP messages off the server as long as they can authenticate.
To configure Outlook Express for authentication, use the Servers tab of the mail account and mark the check box under the Outgoing Mail Server for My Server Requires Authentication. The Settings button enables the user to enter a different account or use the same account as the Incoming Mail Server.
If the organization needs to support POP3 and IMAP users, the next step in configuring the SMTP relay is to select the authentication method under the Authentication button on the Access tab. If this SMTP virtual server will be used for all SMTP connections, the Anonymous Access selection should remain on. If only POP3 and IMAP users will use this virtual server, Anonymous Access should be disabled.
The most secure method to access the SMTP server over the Internet is to remove the Integrated Windows Authentication method and enable the check box for Requires TLS Encryption. In order to select Requires TLS Encryption, you must install a certificate on the server, which can be obtained through the Certificate button on the Access tab for the SMTP virtual server. After the certificate is installed, encryption can be required under the Communication button on the Access tab of the SMTP virtual server.
Select the Require Secure Channel check box under the Communication button if this server will be used to relay messages exclusively for POP3 and IMAP clients. If this server is receiving SMTP mail for the organization, connections will be rejected if they cannot support SSL.
In order to use TLS security for sending messages, the POP3 and IMAP clients need to support TLS or SSL. To configure Outlook Express for SSL, use the Advanced tab of the POP3 or IMAP mail account and select This Server Requires a Secure Connection (SSL).