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.
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.
|
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.
|
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:
1. | Start Exchange System Manager.
|
2. | Navigate
to Administrative Groups\First Administrative
Group\Servers\Server01\First Storage Group\Public Folder Store
(Server01).
|
3. | Right-click Public Folder Store (Server01), and then click Properties.
|
4. | On the Security tab, click Add.
|
5. | In the Enter The Object Names To Select box, type users and then click OK.
|
6. | 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.
|
7. | Click Add. In the Enter The Object Names To Select box, type Senior Managers and then click OK.
|
8. | 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.
|
9. | 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. |