The Exchange Server Troubleshooter - 01 Oct 1998

Why does Windows NT take so long to shut down after I've installed Microsoft Exchange Server?

After installing Exchange Server, many administrators notice a lengthy shutdown delay when they shut down Windows NT Server. Although Microsoft designed the program this way, the delay can be bothersome if you want to restart a server quickly.

Exchange Server consists of several interdependent NT services. In addition, because Exchange Server uses transactions, the system must shut down Exchange services not only in the proper manner but in the proper order. When you install Exchange Server on NT Server, the setup program modifies an NT Registry entry to increase the service shutdown delay timeout from 30 seconds to 120 seconds. The reason for the delay is that Exchange must properly shut down the Information Store and flush all buffers to the disk subsystem before NT shuts down. Understanding the rationale for the delay is usually enough to allay most administrators' frustrations.

However, if you can't stand the delay, there are workarounds. You can modify the Registry and return the setting to its original value. I don't recommend this approach, though, because Microsoft developers have modified the setting for good reasons. Setting the value too low or back to the NT default can corrupt or otherwise disrupt the Information Store when premature shutdown prevents Exchange from writing valuable data to the Information Store. Because this option is so dangerous, I won't describe it further.

Many administrators opt for a common, safer workaround: scripted shutdown of Exchange Server before NT shutdown. You use an NT command (.cmd) script or other mechanism that executes before you initiate an NT shutdown:

NET STOP MSEXCHANGEDS /YNET STOP MSEXCHANGEIMS /Y (if applicable)NET STOP...[you must add a line for each specific service that is pertinent to your configuration]

This script is an automated batch file that shuts down Exchange Server services in the proper order and speeds the eventual shutdown of NT Server.

Is Exchange Server Year-2000 (Y2K) compliant?

As we approach the millennium, many organizations are moving into high gear with regard to Y2K concerns. Officially, Exchange Server 5.5 is the only Y2K-compliant version of Exchange Server. Exchange Server 5.5 Standard and Enterprise Edition along with Outlook 97 (8.03—which ships with Exchange Server 5.5) have been through extensive testing to verify their Y2K compatibility. Microsoft has regression-tested all components such as the Message Transfer Agent (MTA) and various connectors and add-ins. Officially, you must hang your hat on Exchange Server 5.5 for Y2K compliance.

Outlook 98 ships with the Exchange 5.5 Service Pack 1 (SP1) CD-ROM. For Outlook 97 users can obtain a new outllib.dll file for Y2K compliance from http://officeupdate.microsoft.com/updates/updoutlook.htm. Microsoft will also include the outllib.dll in the forthcoming Microsoft Office Service Release 2 (SR2-Outlook 8.04).

Unofficially, no evidence suggests that Exchange Server 4.0 and 5.0 are not also Y2K-compliant. Microsoft simply can't test all the various combinations and variables associated with previous versions, service packs, third-party add-ins, and various mixed environments. However, as a result of customer demand, Microsoft is investigating and testing previous versions of Exchange Server for Y2K compatibility.

One piece of advice for third-party Exchange Server add-on products such as fax servers and gateways is to check with the software developers to ensure that they have thoroughly tested their software for Y2K compliance. Ask them which versions of their product they certify with each version of Exchange Server. To be safe, upgrade to the version that supports Exchange Server 5.5. For comprehensive information about Microsoft software Y2K compliance, visit http://www.microsoft.com/technet/topics/ year2k/product/product.htm. Incidentally, Microsoft Mail is not Y2K-compliant.

Can I replicate public folders from one Exchange Server organization to another?

Your business might need to replicate your organization's public folders from your organization to another. For example, you might maintain a discussion or information forum that you would like to make available to customers or business partners.

Exchange provides no inherent method for replicating these folders. However, because Exchange Server supports Network News Transfer Protocol (NNTP), you can configure your selected internal public folders to replicate (the process is more like duplication than replication) to a foreign organization via NNTP.

Be aware that NNTP replication has several limitations with regard to public folder functionality. If you use NNTP, Exchange Server replicates only the content (individual items) of a public folder; it can't replicate other important features of your Exchange Server public folders, such as specialized rules or custom script-driven applications. Public folder permissions don't survive the trip, either. If you are content with these limitations, replication of Exchange public folders via NNTP can provide valuable information and functionality to you, your customers, and business partners. For information about adding NNTP support to a public folder, refer to the Microsoft Knowledge Base article "XFOR: How to Publish Exchange Public Folders as NNTP" (http://support.microsoft.com/support/kb/articles/q169/9/15.asp) and the white paper "Troubleshooting Guide: Microsoft Exchange Internet Protocols" (http://support.microsoft.com/support/exchange/content/whitepapers/intprot.asp).

I've just added a new connector type and want to update all my existing users with the new default site address for this connector. How can I perform this update?

Updating users is a often a problem when you install an new type of connector for Exchange Server, such as the Lotus Notes connector, Internet Mail Connector (IMC), or another connector type that provides Exchange with additional address spaces. For example, when you add a Lotus Notes connector to an existing Exchange server within your organization, new users that you create will receive a Notes proxy address. However, you might have to manually add a new proxy address for all your existing users. To get around this annoying task, you can take the following steps.

When you've finished regenerating proxy addresses for all your users (this task can take some time with larger Exchange directories), you will have successfully updated your entire organization with the new connector's address space. Both existing users and new users you create will have a proxy address entry for the connector.

I have just installed Exchange Server on a new server. I have created a Site connector and now would like to set up public folder affinity. However, when I attempt to add other sites, I don't see any listed in the list box. What am I doing wrong?

For Exchange Server to know about other sites and servers within your organization, Exchange must have them listed in the Directory. A new server must complete the directory replication process before these entries exist in its local copy of the Exchange Directory. Directory replication can't occur until you install the directory replication connector. First, be sure that a messaging connector (such as a Site connector, X.400 connector, or Dynamic Remote Access Service—Dynamic RAS—connector) is in place. You can configure connectivity to a site either by creating a connector or by adding a site to the Connected Sites property page of an existing connector. Then, configure a directory replication connector in Exchange Administrator by selecting File, New Other and choosing Directory Replication Connector. Configuration of a directory replication connector is not automatic; it requires a separate step. For more information about directory replication and connectors, see Mark Ott, "Intrasite and Intersite Directory Replication," May 1998.

How do I subscribe a public folder to a mailing list?

Subscribing a public folder to a mailing list is simple. Every public folder has a Simple Mail Transfer Protocol (SMTP) address, so you must subscribe that address to the list, using the following steps:

Some list servers require the subscription request to come from the person subscribing to the list. In that case, you must send the subscription message as (i.e., Send As) the public folder. When composing the subscription message, select From on the View menu to expose the From field on the note, and enter the public folder's address. If the folder is hidden from the GAL, you can add it to your PAB from the Administration page of the folder properties, then get it from the PAB, as described above. If you later decide to delete the public folder, make sure you unsubscribe it from the list first, or Exchange Server will return nondelivery reports for all messages sent to the folder.

Exchange doesn't grant Send As permission for public folders by default, even to the folder owner. Even though all the operations involved in subscribing a public folder take place in the Outlook/Exchange client, not Exchange Administrator, you still must be logged on either as the Exchange service account or as an account with Send As permission for the folder, which the administrator can grant only in Exchange Administrator.

How do I prevent someone from using my Exchange server as a relay point on the Internet for unsolicited commercial email (UCE)?

UCE is a widespread problem for many Exchange Server administrators who connect their servers to the Internet. To send UCE, instigators use a well-known SMTP-based mail server as a relay point for sending bulk email across the Internet. By using a well-known Internet host, the sender gives the appearance that the host sent the unsolicited email. For example, if I could use the Compaq mail service as a relay point on the Internet (I can't, because Compaq prevents this practice), Compaq would appear to be the sender of the mail my intended recipients received.

When you configure an SMTP server to allow rerouting for different Internet mail clients (e.g., Post Office Protocol—POP—3 and Internet Message Access Protocol—IMAP—4), you also enable the accepting and relaying of mail for nonlocal recipients. Without restrictions on relaying, clients can connect to the Exchange SMTP service and submit messages for delivery to recipients outside of your organization and thereby use your Exchange server as a relay point for UCE. (For a discussion about this problem, see Douglas Toombs, "Junk Email," Windows NT Magazine, August 1998.)

By default, the Exchange Server Internet Mail Service (IMS) relays mail as specified by the Reroute Incoming SMTP Mail option on the IMS's Routing Properties page. To let you better control this routing function, in Exchange Server 5.5 Microsoft lets you modify four parameters in the Windows NT Registry at HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeIMC Parameters. Table 1 shows the values that you edit.

You can set the RelayFlags parameter to a value between 1 and 4, according to the following definitions:

The RelayDenyList, RelayAllowList, and RelayLocalIPList values consist of a network and an optional subnet mask per line. Order is not important in these lists. Each line has two parts, the network and the subnet mask, separated by a semicolon (e.g., Network; Mask). For example, to let IP host 193.123.4.12 (subnet mask: 255.255.0.0) relay through your server, add a RelayAllowList entry, in the following format:

193.123.4.12;255.255.0.0

After you change these settings, you must restart the IMS to apply them. For more information about configuring these parameters, see the Exchange Server 5.5 Release Notes documentation on the Exchange Server 5.5 CD-ROM.

How can I prevent Exchange Server users from receiving UCE?

Exchange Server 5.5 introduced new features to prevent your Exchange server from receiving this irritating mail traffic. You can configure the Exchange Server 5.5 IMS to disallow delivery of messages addressed from specified Internet domains and users. When you specify a user or domain (using the Registry parameter TurfTable), the IMS aborts messages originating from that user or domain, moves them to a specific directory on the Exchange server, and doesn't deliver the messages to their intended recipients. Typically, the IMS adds users or domains to the TurfTable and specifies a TurfDir on the Exchange Server computer where you will store these messages. Specifying a TurfTable without defining the TurfDir parameter will result in permanent deletion of these messages.

Use regedt32.exe to add the two IMS Registry parameters, which Table 2 shows, for preventing users from receiving UCE. Add the parameters at HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceMSExchangeIMCParameters. Add the entries, which are not case sensitive, one per line with no spaces. For example, if you want to prevent the IMS from delivering all messages from the domain whitehouse.gov to local users in your organization, you enter the following TurfTable entry:

#@whitehouse.gov

You can make TurfTable entries in the format at #@domain.com, @domain.com, or [email protected].

After you change these settings, you must restart the IMS to apply them. For more information on configuring these parameters, see the Exchange Server 5.5 Release Notes documentation on the Exchange Server 5.5 CD-ROM and Microsoft Knowledge Base article "XFOR: Verification of FROM Address in SMTP Messages" (http://support.microsoft.com/support/kb/articles/q155/6/83.asp).

How can I limit access to the Exchange Internet Mail Service (IMS) to specific servers?

Most Exchange Server deployments let all servers in a site send and receive mail via an IMS installed on a server in the site. However, in certain instances, you might want to limit access to the IMS or load balance between multiple IMSs. For example, suppose you have eight servers in a site and have installed the IMS on two of those servers. You want to load balance, or divide the load between the two servers, by having four servers use one IMS and four servers use the other IMS.

The best method to load balance between IMSs is to use IMS scope restrictions. The server's Address Space Restrictions property page lets you restrict the IMS by location. For the scenario I described above, follow these steps:

The Location, or subsite, feature became available in Exchange Server 5.0. Earlier versions of Exchange won't let you use the Location option when you configure server properties.