Contents
Chapter 8 Managing Exchange Server 2003 . . . 195
Common Administrative Chores . . . 195
Monitoring and Troubleshooting . . . 201
Outook Web Access . . . 207
Implementing Security . . . 210
Avoiding Spam . . . 212
Migration, Administration, and Beyond . . . 218
Books
Chapter 8
Managing Exchange Server 2003
In Chapter 7, we revealed the many steps that you need to go through to properly install and configure an Exchange 2003 server and an Exchange 2003 messaging environment. We looked at performing upgrades and migrations from earlier versions of Exchange Server and looked at several important post-installation steps that you should take to set up each Exchange 2003 server for optimal performance. As a bonus, we discussed the enhancements and useful new features available when you install Service Pack 1 (SP1) for Exchange Server 2003.
In this final chapter, we examine important day-to-day administration concerns that can help keep your Exchange 2003 messaging infrastructure up and running and minimize potential downtime. We also discuss how to set up Outlook Web Access (OWA), how to implement important security measures, and how to fight the battle against the ever-increasing barrage of unsolicited commercial email (UCE), also known as spam.
Common Administrative Chores
Much of your day-to-day management of Exchange will take place in the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in because you conduct all Exchange management of users (aka email recipients) within Active Directory. For example, you can
mail-enable all users, groups, and contact objects within Active Directory, meaning you can configure
them to receive email messages. This is different from being mailbox-enabled, which associates an Exchange mailbox with a user account; for example, mail-enabled contacts simply accept email messages and redirect those messages to another email address. Suppose you’ve created a contact object in Active Directory that represents an external vendor who works with your company. This contact object, as Figure 1 shows, can include an email address and other contact information, providing a useful reference for your company’s users.
Figure 1:
Examining Exchange Server contact information in Active Directory Users and Computers
Mail-enabling a contact adds messaging functionality. To mail-enable the contact, right-click it in the Active Directory Users and Computers console, select Exchange Tasks, then select Establish E-mail Address from the list of available tasks. As Figure 2 shows, you’ll provide an alias for the contact and an external email address. This external email address should be the actual address where this contact receives email messages.
Figure 2:
Mail-enabling a contact in Active Directory Users and Computers
This mail-enabled contact can now receive email messages at [email protected] (i.e., the company’s Internet email domain for Exchange Server) and that email will be redirected, or forwarded, to the vendor’s outside email address at [email protected]. You can mail-enable both users and groups.
You follow a similar set of steps to Mailbox-enable a user; you need to select Create Mailbox on the list of available Exchange tasks. As Figure 3 shows, you also must specify the server on which the mailbox will be created and the mailbox store where the mailbox will reside.
Figure 3:
Mailbox-enabling a user in Active Directory Users and Computers
Mailbox-enabled users have several additional tabs available in their Properties sheet within Active Directory Users and Computers. As Figure 4 shows, you can enable or disable specific Exchange features, such as access to Outlook Mobile Access (OMA), OWA, POP3, and IMAP4. You can also modify users’ email addresses on the E-mail Addresses tab.
Figure 4:
Configuring Exchange Server features from a user’s Properties sheet
On the Exchange General tab, you can modify a user’s delivery restrictions, as Figure 5 shows. You have the option here of modifying the delivery restrictions from the default settings for the Exchange organization, thereby overriding the organizational settings. You can also change the user’s storage limits, as Figure 6 shows, which also overrides the default settings established for the mailbox store where the user’s mailbox is hosted.
Figure 5:
Figure 6:
Specifying override settings for an individual user’s Storage Limits
The management of individual Exchange servers, or managing the entire Exchange organization, is accomplished within the Exchange System Manager (ESM) console, not the Active Directory Users and Computers console, and typically consists of monitoring and troubleshooting tasks.
Monitoring and Troubleshooting
Both Windows 2000 Server and Windows Server 2003 provide the Performance snap-in for
monitoring a server’s vital signs. Within the Performance snap-in you’ll find the System Monitor tool. The System Monitor provides built-in status monitoring for each Exchange server in your organization, which is useful. Although not as full-featured as other monitoring and notification software (such as the Microsoft Operations Manager—MOM), the basic status monitoring that System Monitor provides is useful and can be customized to fit your needs. For example, as Figure 7 shows, you can configure a server with multiple monitoring metrics, such as the status of a particular service or CPU utilization. These monitors define the conditions under which the server’s status will be considered Available, Warning, or Critical. In Figure 7, the server will enter a Critical state if the CPU percentage exceeds 100 percent for 5 minutes or if the default Exchange services are stopped.
Figure 7:
Configuring Performance Monitoring Metrics in the ESM
Any server or service that enters the Warning or Critical state will generate a notification—a message signaling a problem. In addition to monitoring individual Exchange servers, you can also have status monitors for things like the Internet Mail SMTP Connector. You can use the ESM (under Tools, Monitoring and Status, Notifications) to define how notifications are treated. By configuring an email notification (which Figure 8 shows), you can receive an email message when a problem occurs. You can also create script notifications, which execute a specified command-line executable whenever a monitored item enters either the Warning or Critical state.
Figure 8:
Configuring email notification parameters for monitoring Exchange server
For troubleshooting, the ESM provides the Message Tracking Center. The Message Tracking Center lets you follow a particular message through the delivery process so that you can see exactly how Exchange deals with it. This understanding can be invaluable in troubleshooting various problems. You must first enable message tracking on a per-server basis, as Figure 9 shows. In the ESM, you’ll find the Enable Message Tracking checkbox on the General tab of an Exchange server’s Properties sheet. Don’t leave message tracking enabled for longer than necessary, as it can place a significant additional burden on the server.
Figure 9:
Turning on Message Tracking for an Exchange server
After message tracking is turned on, you can use the Message Tracking Center to search for messages and view their tracking status within the server. As Figure 10 shows, the Message Tracking Center lets you enter search criteria for messages, such as the sender or recipient names and the approximate time and date that the message was sent.
Figure 10:
Specifying search criteria in the Message Tracking Center
From the list of matching messages, you can double-click each message to view its status, which Figure 11 shows. Each step of the message routing and delivery operation is listed, helping you to determine exactly where a message is in the process. In Figure 11, a message destined for an external recipient has been queued for delivery, but not yet delivered.
Figure 11:
Viewing Message History in the Message Tracking Center
You can also directly monitor the queues on each server. In the ESM, expand the administrative group in which the server that you want to monitor is located. Next, expand the Servers folder, expand the container icon for the server, then click the Queues object to display the various message queues for that server in the right-hand pane. For example, Figure 12 shows the Internet Mail SMTP Connector queue with that single outgoing message ready for delivery. The message hasn’t yet been delivered, which might indicate a problem with the connector, with SMTP connectivity to the Internet, or even a DNS name resolution problem. The status message at the bottom of the window—The
Figure 12:
Monitoring message queues on an individual Exchange server
Outlook Web Access
OWA is managed almost entirely from within the Internet Information Services (IIS) Manager, not the ESM. As Figure 13 shows, the properties for the Exchange virtual root, under IIS’ Default Web Site, points to the Exchange store (BackOfficeStorage) as its default path. To configure OWA to require Secure Sockets Layer (SSL) connections or to modify the ports OWA uses, simply modify the properties of the Default Web Site within IIS. SSL uses port 443 by default instead of port 80, which is the default port for unsecured HTTP Web connections.
Figure 13:
Modifying OWA settings in the IIS Manager console
Figure 14 shows practically the only OWA property that you need to manage within the ESM, and you access it as a property of the Exchange Virtual Server from within System Manager (under the HTTP section of the Protocols folder within each server running OWA). This property enables
forms-based authentication, letting users log on to OWA from a Web page, rather than a pop-up
Figure 14:
Enabling forms-based authentication for OWA in the ESM
OWA for Exchange Server 2003 is otherwise almost entirely self-configured and, as Figure 15 shows, provides a user experience remarkably similar to Outlook 2003.
Figure 15:
An example of OWA displayed within Microsoft Internet Explorer (IE)
Implementing Security
Other than implementing strict relay restrictions to ensure your server isn’t used as a base for spammers, Exchange lets you configure granular security permissions for nearly every object in System Manager. Most commonly, you’ll delegate control over entire Administrative Groups, allowing
• Exchange Administrator: This permission lets the delegated group modify only Exchange system information (and not individual mailboxes).
• Exchange Full Administrator: This permission lets the delegated group do anything.
Figure 16 shows a sample delegation, with two different users being granted two different types of permissions: Exchange Full Administrator for the Administrator and Exchange Administrator for sallys. Note that the built-in Administrator account is given Exchange Full Administrator permission by default at the organization level and the Administrative Group to which control is being delegated inherits that permission. You can also delegate control at the organization level.
Figure 16:
Delegating control to users and groups at the Administrative Group level
As Figure 17 shows, security can also be applied individually to servers and many other objects within an Exchange Server messaging infrastructure. Exchange Server security permissions work in very much the same way as NTFS or Active Directory security permissions, but of course, the permis-sions that apply to Exchange are somewhat different than the permispermis-sions that apply to NTFS drives or to Active Directory objects. However, managing security on a per-server or per-object basis can be time-consuming, tedious, and confusing—you need to check many levels when problems occur or whenever security permissions need to be changed.
As a rule, try to delegate permissions at the organization or Administrative Group level,
whichever is appropriate, to minimize security maintenance overhead. Troubleshooting is much easier when permissions have been delegated; trying to diagnose security permissions problems when many settings have been configured individually can be likened to looking for a needle in a haystack.
Figure 17:
Figure 18:
Viewing the Connection Filtering tab for configuring RBL settings and exceptions
You should seriously consider adding a third-party mail-filtering service to your Exchange servers. These services work by scanning the content of incoming mail and assigning a score, which represents the likelihood that the message is spam. Some products automatically move messages to users’ Junk Email folder so that users can manually review spam to check for false positives (i.e., blocked legitimate email messages); other products require an administrator to scan through blocked messages for false positives.
You’ll want to ensure that your Exchange servers don’t become a potential source of spam sent from unauthorized users. The best way to accomplish this is to configure relay restrictions, which prevent unauthenticated users from using your server to send email messages. You configure these restrictions on a per-server basis. Open the Protocols folder in the ESM, select Protocols, then select SMTP. Modify the properties of the Default SMTP Virtual Server and select the Access tab. Click the Relay button to modify relay restrictions. The defaults, which Figure 19 shows, are fairly secure: Messages cannot be relayed from any computer, unless its user has authenticated to Exchange.
Figure 19:
Setting relay restrictions for the Default SMTP Virtual Server in the ESM
Relaying is the act of delivering a message not intended for a local recipient. So, accepting
incoming email messages for your users is not considered relaying because they are local to the Exchange organization (meaning they have mailboxes in the organization). Relaying is accepting email messages for nonlocal users, then redelivering those email messages to those users; it is how most spammers do their dirty work. Relaying helps spammers cover their tracks and makes it seem as if their spam is coming from your network. Your users need the ability to relay, because they will be asking your Exchange server to deliver email messages to nonlocal users; that’s the very essence of sending email messages, after all.
Exchange 2003 environment or on versions of Exchange Server earlier than Exchange 2003. However, Microsoft does support deploying the Intelligent Message Filter on Exchange 2003 servers that act as gateways to protect Exchange 2000 or Exchange 5.5 servers. However, this type of configuration cannot take full advantage of all the Intelligent Message Filter’s features. To obtain the Intelligent Message Filter, you must download it from Microsoft’s Web site and install it as an add-on to Exchange 2003.
To download a copy of the ExchangeIMF.msi file (about 9MB), go to http://www.microsoft.com /exchange/downloads/2003/imf/default.asp. Double-click the MSI file to launch the installation routine—the setup program is very straightforward. Be sure to install the Intelligent Message Filter during nonproduction hours because IIS and Exchange services are stopped then restarted during the installation. Naturally, you need to first install the Intelligent Message Filter in a test environment to determine its usefulness and its drawbacks for your particular organization.
After you successfully install the Intelligent Message Filter, you’ll notice that a new component has been installed under the Exchange server’s SMTP folder in the ESM. Expand the administrative group for the server in which the Intelligent Message Filter is installed, expand the Servers folder, expand the Protocols folder, then expand the SMTP folder. You’ll see the new Intelligent Message Filtering component listed beneath the Default SMTP Virtual Server object. To enable the Intelligent Message Filter, right-click the Intelligent Message Filtering icon, then select Properties. By default, the Intelligent Message Filter is turned off. Mark the checkbox for each appropriate SMTP Virtual Server and click OK to turn on Intelligent Message Filtering, which Figure 20 shows.
Figure 20:
After you have turned on Intelligent Message Filtering, you need to configure the preliminary threshold tolerances for your organization for both Gateway Blocking and Junk E-mail settings. The Intelligent Message Filter assigns a Spam Confidence Level (SCL) number between 1 and 9 to each message that passes through each SMTP Connector on which the Intelligent Message Filter has been enabled. For example, an email message that is assigned an SCL rating of 1 is almost guaranteed to be a legitimate message. Conversely, an email that is assigned a rating of 5 or greater is virtually certain to be a UCE message—spam. In establishing the Intelligent Message Filter thresholds for your Exchange 2003 organization, keep in mind that if you specify a lower setting for the Gateway Blocking Configuration, the Intelligent Message Filter will block more potential spam messages, but you also increase the likelihood of blocking legitimate email messages.
To configure SCL threshold settings in the ESM expand the Global Settings folder, right-click the Message Delivery object, and select Properties. The Intelligent Message Filter adds a new tab to the Properties sheet called Intelligent Message Filtering, which Figure 21 shows. From the Intelligent Message Filtering tab, specify the Gateway Blocking Configuration number and an action for blocking messages for those messages that are assigned a rating equal-to or greater-than the specified setting: No Action, Reject, Archive, or Delete. Remember that these settings apply to the entire Exchange Server
organization. The No Action setting allows the message to pass through the SMTP connector. The
Reject setting tells the SMTP Connector to return (or bounce) the message back to the sender. The Archive setting causes the SMTP Connector to route those messages to be stored as .eml files in the
<drive letter:>\Program Files\exchsrvr\mailroot\vsi 1\UceArchive folder.
To review these messages, double-click each one to open it within Outlook Express. Be aware that this folder can fill up rapidly with thousands of messages—too many messages to manually look at. You might consider using a third-party tool, such as Intelligent Message Filter Archive Manager from GotDotNet, to more efficiently cycle through hundreds or thousands of archived emails. (You can download this utility at http://www.gotdotnet.com/Community/Workspaces/workspace.aspx?id =e8728572-3a4e-425a-9b26-a3fda0d06fee.) Finally, the Delete setting tells the SMTP Connector to immediately drop all the messages that meet the criterion.
Figure 21:
Specifying SCL thresholds for the Intelligent Message Filter in the ESM
Messages that have been assigned a lower SCL rating than the threshold specified for the Gateway Blocking Configuration can pass through the SMTP Connector and find their way to the proper recipient’s mailbox. However, you might have noticed the Store Junk E-mail Configuration section at the bottom of the Properties sheet. This threshold determines whether messages are to be moved into users’ Junk E-mail folders based on each message’s SCL rating. The Store Junk E-mail
Configuration threshold setting must be lower than the Gateway Blocking Configuration threshold setting or else an error message will inform you of this rule. So, a message might get past the
Gateway Blocking threshold setting, but it might not survive the Store Junk E-mail threshold setting, depending on the threshold settings and the message’s SLC rating.
Note
If you change either of the SLC threshold settings for the Intelligent Message Filter on the Message Delivery Properties sheet, we recommended that you stop then restart the Exchange Information Store service. If you do not restart this service, you might experience unpredictable results when using the Intelligent Message Filter.
Of course, the Intelligent Message Filter add-on for Exchange Server 2003 is not the only anti-spam solution floating around. Third-party vendors provide several valuable tools that you should consider before choosing an antispam product. Some of the most popular products include:
• GFI MailEssentials • McAfee SpamKiller • Nemx Power Tools • NetIQ MailMarshal
• Sunbelt Software iHateSpam for Exchange • SurfControl E-mail Filter
• Sybari Spam Manager
• Symantec Brightmail Anti-Spam
• Symantec Mail Security for Microsoft Exchange • TrendMicro ScanMail for Microsoft Exchange • Vamsoft Open Relay Filter (ORF)
Migration, Administration, and Beyond
This chapter provides the major fundamentals to help you manage your newly upgraded Exchange server environment including setting up OWA, mailbox-enabling users, mail-enabling contacts, implementing security measures, and applying the latest antispam technology to keep your Exchange messaging infrastructure stable, secure, and as free from spam as possible. This chapter also covers the basics of how to set up performance monitoring and how you can troubleshoot message delivery problems with the Message Tracking Center.
Throughout this eBook, we have laid the major groundwork necessary to migrate your network infrastructure to Windows Server 2003 and your messaging infrastructure to Exchange Server 2003. Remember that throughout the book we pointed out many additional resources to review for further information and many other tools to consider for assistance with your migration. Because of the complexity and individuality of networks, you will undoubtedly need to analyze and prioritize this information appropriately to meet the needs of your particular environment. Naturally, due to the evolving nature and the fast-moving world of computers and information technology, you will undoubtedly need to continue making changes, installing service packs, and applying new feature packs on a continuing basis to maintain optimal functionality and performance. With this eBook as a
