- 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
- Best Practices
Performing Postinstallation Configurations
After Exchange 2003 has been installed and customized, there are a few cleanup and implementation steps you should take:
Disable unnecessary services.
Remove information stores that won't be used.
Set up routing group connections.
Enable logging and message tracking.
Delete mailbox and public folder stores.
Although Exchange 2003 does a much better job by not automatically installing dozens of different utilities and services the way previous versions of Exchange did, it still installs some default services that might not be used by the organization. For security and administration purposes, if a service is not used, it should be disabled. To disable services that are commonly unusedsuch as IMAP, POP3, NNTP, or SMTPdo the following:
Select Start, All Programs, Administrative Tools, Services.
Scroll down to the IMAP4 Service.
Double-click on the service.
Under the Startup Type section, choose Disabled.
Under the Service Status section, click Stop.
Repeat steps 15 for POP3, NNTP, and SMTP, as applicable.
If IMAP, POP3, and NNTP are used on a server, such as a front-end system hosting remote mail users, those services should not be disabled. It's common on back-end servers where IMAP or POP3 is not used that the service could be disabled; it's also common for organizations that use Exchange just for email and do not need NNTP on any of their servers. For servers or systems that are not routing mail, such as those set up solely as Exchange System Manager administration servers, the SMTP service should be disabled.
Removing Information Stores
By default, an information store that holds Exchange databases is created on each Exchange server installed in the organization. However, dedicated front-end servers that are just the Web front-end systems do not require information stores or databases. In those cases, the information stores should be deleted. To delete the information stores that are unneeded on front-end servers, follow these steps:
Select Start, All Programs, Microsoft Exchange, System Manager.
Navigate to Administrative Groups, Administrative Group Name, Servers, Server Name, Storage Groups.
Right-click on the mailbox store and choose Delete.
Click OK and delete the database files manually.
Before deleting any database or information store, unless you are positive the database or information store is completely empty and unused, you might want to do a full backup of the database, store, and systemin case a user's mailbox was inadvertently hosted on the system. Sometimes during an early implementation of Exchange, an organization might start with just one or two servers in a pilot test environment. If a mailbox was stored on one of the test servers, it might eventually become the front-end server for the organization. Backing up a system is safer than making assumptions and regretting the decision later. Using the NTBackup utility covered in Chapter 31, "Backing Up the Exchange Server 2003 Environment," is a quick way to back up a system.
Setting Up Routing Group Connectors
Routing group connectors should be used in situations where there is greater than 64KB of available bandwidth between the routing groups. If there is not sufficient bandwidth, SMTP or X.400 connectors should be used to connect the routing groups. Routing group and routing group connector designs should follow the organization's physical connectivity links. Four basic routing group connector strategies can be implemented based on the organization's physical network links:
Full Mesh In a full mesh all routing groups connect to all other routing groups. Unless there are only a few routing groups the administrative overhead for implementation becomes unbearable. This design can also be a waste of administrative resources if there isn't the WAN link redundancy to support the design.
Partial Mesh A partial mesh tries to create the benefits of a full mesh without the added administrative overhead. If the WAN design is a partial mesh, build the routing groups to follow the partial mesh.
Hub and Spoke In a hub and spoke design one routing group becomes the center of the universe and all other routing groups connect to it. In larger networks there can be multiple hubs in the enterprise, and the hubs are joined together in a full or partial mesh. This design is simple to implement and maintain but creates a single point of failure at the hub. This design is an option for locations that do not have any WAN link redundancy.
Linear In a linear design routing groups connect to only one other routing group in a straight line. Linear designs are not recommended.
To create a new routing group, follow these steps:
Navigate to Administrative Groups, Admin Group I, Routing Groups, HO, as shown in Figure 3.7.
Right-click Connectors and choose New Routing Group Connector.
Type a name for the connector, as shown in Figure 3.8.
Click These servers can send mail over the connector, and click Add to choose a server or check Any local server can send mail over the connector.
Figure 3.7 Traversing the Exchange System Manager for routing groups.
Figure 3.8 Routing group configuration screen.
The General tab of the routing group connector defines a few significant items that administrators should understand when configuring the connector:
Connect this routing group with Specifies the destination routing group for the RGC.
Cost Arbitrary cost assigned by the administrator, which can be used to control which connector is used first if multiple connectors exist.
Server Allows any server, or specifies specific servers allowed, to transfer mail to the destination routing group. By specifying specific servers, a bridgehead server is nominated. By specifying multiple servers, backup bridgehead servers are identified. The order of the servers in the list specifies which server is used first.
Do not allow public folder referrals Disables the user's ability to access public folder content that is homed in the routing group connected to that server.
Click on the Remote Bridgehead tab and click Add to choose a server. After entering the bridgehead server selection, you will see a screen similar to Figure 3.9.
Figure 3.9 Bridgehead server configuration.
Select Yes to create a routing group connector in the remote routing group.
Enabling Logging and Message Tracking
Logging and message tracking are common functions enabled by Exchange administrators early on in an Exchange implementation to help the administrator validate that messages are flowing through the environment. By enabling the logging and message tracking function, the administrator can then run a report to find out which route a message took to get from one server to another, and how long it took for the message to be transmitted.
Many administrators never use the logging and message tracking function and simply assume that messages are getting from point A to point B successfully. In many environments, although messages reach their destination, they are routed from one site to another and once around the globe before being received by a mail user in the same site facility. Misconfigured routing group connectors, DNS errors, or other networking problems are often the cause. So it's usually helpful to monitor messages to ensure that they are being routed and processed as expected.
To enable logging and message tracking, follow these steps:
Open Exchange System Manager.
Navigate to Administrative Groups, Admin Group I, Servers, Server Name.
Right-click on the server object and choose Properties.
Select Enable subject logging and display and enable message tracking.
Type a number indicating days to keep the message tracking log files, as shown in Figure 3.10.
Figure 3.10 Configuring logging for message tracking.
Dismounting and Deleting Public Folder Stores
Unused public folder stores should be removed for security and administration purposes. Frequently, organizations that separate mailbox servers from front-end servers from public folder servers do not need public folder databases on the front-end or mailbox servers.
To dismount and delete public folder stores, follow these steps:
Expand the servers and storage group.
Right-click the public folder store and choose Dismount.
Click Yes to dismount the store.
Right-click the public folder store and choose Delete.
Click Yes twice.
Click Yes to delete the store.
Select OK to the message that says you have to select another public folder store for the system folders and that public folder store will have to be dismounted and remounted for the changes to take effect.
Choose a new public folder store for this server's system folders.
Click OK. You have to manually delete the database files for the store by going to the mdbdata directory and deleting pub1.edb and pub1.stm.
Right-click the mailbox store and choose Dismount.
Click Yes to dismount the store.
Right-click the mailbox store and choose Delete.
Click OK. You have to manually delete the database files again as previously stated.
Unless you are positive that the database or information store is empty, you should do a full backup of the database, store, and system, in case the public folder store hosted the authoritative copy of the public folder information.
Using System Policies to Manage Mailbox and Public Stores
Many of the settings that can be manually set on each mail and public store can be set through a system policy to simplify the settings configuration. Standardizing Exchange server settings in a large deployment was always tough for Exchange Server 5.5 because each setting had to be manually set on every server. With a system policy, the mail and public store settings for limits, deleted item retention, and so on can be set through the policy, and the policy can be applied to the stores. Each administrative group has its own set of policies for the stores. When a policy is applied, the setting that the policy overrides displays as grayed out on the mailbox or public store. Administrators have the choice of choosing for which property pages for the mail or public store they want to configure policies.
To configure and apply a policy, follow these steps:
In the Exchange System Manager, in the Administrative Groups container, right-click on the administrative group you want to manage and select New, System Policies Container.
Right-click on the System Policies container and select New. Then select either Mailbox policy, Public store policy, or Server policy.
When a properties pages appears, enter a name you want to identify with this policy.
Right-click the new policy and select Add Mailbox Store, Add Public Store, or Add Server, and then select the appropriate store or server. Click on OK to complete this task.
To force the policy to be applied immediately to all stores, right-click the policy and select Apply Now.
After the policy is created, it can be modified by right-clicking the policy and selecting Properties.
Because the icon for the Mailbox or Public policies are the same, name the policy something descriptive to indicate it's a Mailbox or Public store policy.
Best Practices for Configuring Storage Groups and Databases
After configuring hundredsif not thousandsof storage groups and databases in beta and production environments, the following best practices have been determined:
Keep databases small to keep restore and maintenance intervals short. The database size is organization-specific and depends on the speed that maintenance and restores run on the server hardware and the organization's Service Level Agreements for messaging services.
Choose to create additional databases before creating additional storage groups to avoid overhead on the server for log file management.
Use no more than four databases per storage group. This will leave one database position open in each storage group for offline database maintenance.
Do not use circular logging.
Verify that a successful backup is performed every day and the logs have been purged.
Use full backups every day if possible.
Periodically verify the backup using an isolated lab.
Leave online system maintenance on and stagger the database maintenance times so that all databases and storage groups aren't trying to run maintenance at the same time.
Do not use the prohibit-send option when configuring storage limits as a courtesy to end-users.
Keep deleted items for at least seven days and deleted mailboxes for 30 days. Use the option to not remove the items permanently until the store is backed up.
Delegating Administration in Exchange 2003
The delegation of permissions can occur at the organizational or administrative levels. There are three levels of permissions that exist in Exchange 2003:
Exchange Full Administrator This level enables the administrator to add, delete, modify, and rename objects, with the ability to change security permissions. These rights are granted to global messaging administrators and at the administrative group where boundary of control changes.
Exchange Administrator This administrator level offers the add, delete, modify, and rename objects permissions. However, this level cannot change security permissions. This level is usually the standard level granted to individuals who need to manage or administer Exchange on a regular basis.
Exchange View Only Administrator With this level, you can view the configuration settings in Exchange System Manager. This level is usually granted to administrators who provide operational support (reviewing logs, creating reports, validating connectivity, and message routing) and do not necessarily need to change settings or configurations directly.
It's easier to delegate administration to a group than to a user. To delegate administration, right-click the administrative group or organization and select Delegate Control to launch the Delegation Wizard. Select the group or user from the Active Directory object picker dialog box and set the Exchange administration role, as shown in Figure 3.11. Then click Next and Finish to apply the permissions throughout the Exchange organization.Figure 3.11 Delegating administration to an AD group.
Being an Exchange Full Administrator or Exchange Administrator also requires that the group or user be a member of the server local administrator group. View-only administrators only need to be able to log on locally to the Exchange server. The Exchange Administration Delegation Wizard will not set permissions on the server itself, so permissions on the server must be set manually through Computer Management.