Troubleshooting the Exchange Server 2003 Organization

6/18/2011 4:16:11 PM

While some faults are restricted to specific Exchange Server 2003 servers, others affect the entire Exchange Server 2003 organization. Problems with public folders can affect everyone in your organization, as can problems with virtual servers. If you use a back-end/front-end configuration, it is easy to misconfigure certain parameters, and you also need to ensure that your front-end and back-end servers can communicate through your firewall. Connectivity problems can prevent your Exchange Server 2003 servers from accessing Active Directory and DNS, which will in turn affect your whole organization.

Troubleshooting Public Folders

Public folders can contain internal company information and can also be used for collaboration projects with partner organizations and to give information about your company to external users. Problems in public folders therefore impinge upon the image that your organization presents to its own employees, to its partner organizations, and to the world at large. Any problems that affect public folders need to be resolved urgently.

Some of the problems that can occur with public folders concern the limits imposed by any public store policies that you decide to create. There are sound reasons for limiting the size of public folders and the size of individual items within any folder. However, you need to be proactive in deleting any items that are no longer required. Users who can post items to a public folder will report warnings and write prohibitions as errors. Also, it reflects badly on your organization if some of the content of a public folder is irrelevant or out of date. You can delegate the task of ensuring that obsolete items are deleted. Indeed, you should do so. As an administrator, you are not in a position to judge whether items posted by, for example, the human resources department can be deleted. However, you do need to keep a close eye on folder size.

If you have a dedicated public folder server, the task of restoring public folders can lead to failure reports because you need to dismount a public folder to restore it. Sometimes this is inevitable, for example, if the data in a public folder is corrupt. Trial restores of public folders, however, should be done on a recovery server in this instance.

Another possible source of error is when you have a public folder that should be accessible through e-mail. Public folders are not mail-enabled by default, and you need to enable this function.

However, the main source of errors in public folders is incorrectly configured permissions. If, for example, you allow too many users to create top-level folders, then your folder tree will become large, unorganized, and difficult to browse or manage. You can control permissions to create top-level folders by right-clicking your Exchange organization in Exchange System Manager and granting the permission only to selected individuals or groups. Figure 1 shows the Create Top Level Public Folder permission being granted to Don Hall.

Figure 1. Granting the Create Top Level Public Folder permission

Another common permission problem occurs when users who should only be permitted to read items in a public folder are also granted write or delete permission. In general, users should have only read permission to public folder items, with write and delete permissions being granted very sparingly. Remember also that permissions granted on a high-level public folder will, by default, propagate to lower-level folders. If permissions are changed at the wrong level, errors can result.

Troubleshooting Virtual Servers

Protocol logs provide a powerful method of recording every detail of every event that occurs in each individual virtual server. If, for example, a message is rejected because it is oversized, this can be deduced from the SIZE xxxxxxx entry in the SMTP virtual server’s protocol log. Diagnostic logging is configured using Exchange System Manager, except for Hypertext Transport Protocol (HTTP) virtual servers, for which you use IIS Manager and configure diagnostic logging for the Web site associated with the virtual server.

Diagnostic Logging

Diagnostic logging can assist in troubleshooting both virtual servers and the general health of an Exchange Server 2003 server and of the Exchange Server 2003 organization. You can configure the level of diagnostic logging on the following services:

IMAP4SVC This service allows users to access mailboxes and public folders through IMAP4. Detailed logging can help locate faults on IMAP4 virtual servers.
MSADC This service runs connection agreements if the Active Directory Connector is installed.
MSExchangeAL This service allows users to address e-mail through address lists.
MSExchangeDSAccess This service allows Exchange access to Active Directory.
MSExchangeIS This service allows access to the Information Store.
MSExchangeMTA This service allows X.400 connectors to access the message transfer agent (MTA).
MSExchangeMU This service replicates Exchange configuration information changes to the IIS metabase.
MSExchangeSA This counter records an entry when Exchange uses Active Directory to store and share directory information.
MSExchangeSRS This counter records an entry whenever Site Replication Services are used to replicate computers running Exchange 2000 Server or later with computers running Exchange Server 5.5.
MSExchangeTransport This counter records an entry whenever SMTP is used to route messages. Configuring the diagnostic logging level can assist in troubleshooting SMTP virtual servers.
POP3SVC This counter records an entry whenever POP3 is used to access e-mail. Configuring the diagnostic logging level can assist in troubleshooting POP3 virtual servers.

Encoding and Relaying

Errors can occur in IMAP4 and POP3 virtual servers if incorrect encoding methods are specified. Often you can solve the problem by creating an additional virtual server and allowing access to a group of clients with particular encoding requirements. If only a few clients have requirements that differ from those of the majority, then you can configure client settings on a per-client basis.

Open relaying can cause problems with SMTP virtual servers. Relaying is disabled by default, but IMAP4 and POP3 clients need to use the facility so that they can use SMTP to send e-mail. Relaying can be enabled for specific clients, but it is usually better practice to create an additional SMTP virtual server that permits relaying and allows access only to POP3 and IMAP4 clients.

Troubleshooting Front-End and Back-End Servers

There are several advantages to a front-end and back-end configuration. Front-end servers do not host mailboxes and can be located outside the main firewall. Back-end servers can use the Microsoft Cluster Service for failover protection while front-end servers can use Network Load Balancing to enhance performance. The use of front-end servers means that mailboxes on your domain can be accessed using a single Uniform Resource Locator (URL), no matter what back-end server you put them on. You can move mailboxes from one back-end server to another, and such a move is invisible to the end user.

However, the advantages that the configuration offers bring their own troubleshooting issues. Front-end servers need to be able to communicate with back-end servers through your firewall without compromising either security or usability. Load balancing clusters are not applicable to back-end servers, nor are Windows clusters to front-end servers, and incorrectly configured clustering can lead to problems. A failure of a mailbox store or a virtual server on a back-end server can look like a fault on a front-end server, and it is important to track messages and find out where the fault occurred.

You need to create a virtual HTTP server on each back-end server to handle front-end requests. A failure on any one of these servers can result in Outlook Web Access (OWA) clients being unable to send mail to or receive mail from your domain.

For all of these reasons, the techniques for troubleshooting communication across a firewall, the use of Cluster Administrator, and the use of virtual server troubleshooting techniques such as protocol logging become even more important when you have a back-end/front-end configuration. The following problems are also common in this configuration:

Authentication is misconfigured The implementation of authentication settings varies between server roles. On front-end servers, IMAP4 and POP3 virtual servers use basic authentication, and this cannot be changed. On POP3 and IMAP4 virtual servers on back-end servers, you can select basic authentication or Integrated Windows Authentication. Integrated Windows Authentication cannot be specified on front-end HTTP virtual servers. Because authentication methods vary with the server type (for good reasons), it is sometimes difficult to work out the settings that meet your required objectives and easy to misconfigure authentication.
Users are disconnected when downloading messages On back-end servers, the connection timeout setting limits the length of time for which a client is permitted to remain connected to the server without performing any activity. On front-end servers, the connection timeout setting limits the total length of the client’s session, regardless of client activity. A common configuration error is to set back-end connection timeout values on front-end servers. You need to configure this setting on your front-end servers so that your users can download the maximum message size permitted over the slowest supported connection speed without being disconnected.
Calendaring settings on front-end POP3 and IMAP4 virtual servers are ignored Exchange Server 2003 does not recognize any URL settings configured on the Calendaring tab of IMAP4 and POP3 virtual servers on your front-end servers unless you configure the corresponding virtual servers on your back-end servers to use front-end settings.

Troubleshooting Connectivity

Because connectivity problems can prevent Exchange Server 2003 from installing. In addition to netdiag, you can use ping to test connectivity with domain controllers, DNS servers, Exchange Server 2003 servers, IIS servers, and other significant hosts on your network. If you can ping by Internet Protocol (IP) address but not by hostname, then this indicates name resolution problems and possibly a problem with DNS.

You can use telnet to check whether a TCP port (for example port 25 for SMTP) can be opened to a receiving host and whether the receiving host is responding. Telnet is useful for testing connectivity over a firewall that blocks the Internet Control and Messaging Protocol (ICMP) on which ping depends.

You can use the nslookup command to query DNS to confirm that DNS is working properly and that MX and A (host) records exist for a particular Exchange Server 2003 server or for all such servers in a domain. You can, for example, use the nslookup – querytype=mx tailspintoys.com command to return all the MX records for the tailspintoys.com domain.

Practice: Limiting Write and Delete Permissions to Public Folders

In your organization, only the senior managers group, which contains users Sean Alexander, Don Hall, and Kim Akers, is permitted to place information in public folders. Only Don Hall is permitted to delete files in public folders. Domain administrators have full control over public folders for administrative purposes. All other users have only read permission. This practice sets up these permissions.

Exercise 1: Create the Senior Managers Security Group

This exercise assumes that mail-enabled accounts exist for Kim Akers, Don Hall, and Sean Alexander.

To create the Senior Managers security group, perform the following actions:

1.	On Server01, open the Active Directory Users And Computers console.
2.	Expand TailSpinToys.com, right-click Users, click New, and then click Group.
3.	On the New Object–Group page, in the Group Name box, type Senior Managers.
4.	Ensure that the Group Scope is Global and the Group Type is Security, as shown in Figure 2. Click Next. Figure 2. Specifying the Senior Managers global security group
5.	You have the option at this stage of mail-enabling the group. However, the use of mail-enabled global security groups is not recommended and is not appropriate in this exercise. Click Next.
6.	Click Finish.
7.	In the details pane of Active Directory Users And Computers, right-click Senior Managers, and click Properties.
8.	On the Members tab, click Add.
9.	In the Enter The Object Names To Select box, type Don Hall.
10.	Click Check Names, and then click OK.
11.	Repeat the procedure described in steps 8, 9, and 10 to add Kim Akers and Sean Alexander to the security group.
12.	The Senior Managers Properties dialog box should contain the entries shown in Figure 3. Click OK to close the dialog box. Figure 3. The Senior Managers Properties dialog box
13.	On Server01, open the Domain Controller Security Policy console and click User Rights Assignment.
14.	In the details pane, double-click Allow Log On Locally and add the Senior Managers group to that right. This lets you test the configuration that you will carry out in the next exercise. In a production network, you would not typically grant ordinary users log on locally rights on a domain controller.

Exercise 2: Configure Permissions on a Public Folder Store

In this exercise, you configure permissions such that the Senior Managers group can add files to the public folder store and amend files, but only Don Hall can delete files that were created by other users.

To configure permissions on a public folder store, perform the following actions:

Start Exchange System Manager.

Navigate to Administrative Groups\First Administrative Group\Servers\Server01\First Storage Group\Public Folder Store (Server01).

Right-click Public Folder Store (Server01), and then click Properties.

On the Security tab, click Add.

In the Enter The Object Names To Select box, type users and then click OK.

In the Group Or User Names box, click Users. In the Permissions For Users box, clear all the Allow check boxes except Read, Execute, Read Permissions, List Contents, and Read Properties.

Click Add. In the Enter The Object Names To Select box, type Senior Managers and then click OK.

In the Group Or User Names box, click Senior Managers. In the Permissions For Users box, clear all the Allow check boxes except Read, Write, Execute, Read Permissions, List Contents, and Read Properties. Figure 4 shows permissions being specified for the Senior Managers group.

Figure 4. Specifying permissions for the Senior Managers group

Click Add. In the Enter The Object Names To Select box, type Don Hall and then click OK.

10.

In the Group Or User Names box, click Don Hall. In the Permissions For Users box, clear all the Allow check boxes except Read, Write, Execute, Delete, Read Permissions, List Contents, and Read Properties.

Note

Write permission enables users to create files, change the content of files, and delete files that they created. Delete permission allows users to delete files that were created by other users.

11.

Click OK to close the dialog box.

12.

Open Outlook and create a new public folder called My Public Folder. Post a message to that public folder.

13.

Log off, and then log on as Kim Akers.

14.

Open Outlook and investigate what you can and cannot do in My Public Folder. You should, for example, be able to post items to the folder.

15.

Log off, and then log on as Don Hall.

16.

Open Outlook and investigate what you can and cannot do in My Public Folder. Discover whether Don Hall has any more rights than Kim Akers.

17.

Experiment with changing the permissions that the Senior Managers group and Don Hall’s individual user account have on Public Folder Store (Server01). Ensure, however, that you are logged on as Administrator at the end of this exercise.