Mail Flow Tools
The
Mail Flow Troubleshooter is a utility that assists with troubleshooting
common mail flow issues in an Exchange Server environment.
Administrators can input the issues they are encountering, and the
utility gathers information, diagnoses the environment, and presents a
recommended plan of action.
The
Tracking Log Explorer utility allows administrators to search for
messages and track them through the Exchange Server environment.
Message tracking can be extremely useful for determining where a
message was delayed or “stuck” in the messaging environment.
Message
Tracking, which once was part of the Mail Flow Tools is not part of the
Exchange Administration Center message tracking section. The messaging
tracking enables an administrator to search the mail store for messages
that meet a certain criteria.
Exchange Queue Viewer
The
Exchange Queue Viewer is another utility included in the Exchange
Toolbox. The Exchange Queue Viewer is used to view the contents of the
queues for each particular protocol on a server. Although this tool is
more of a troubleshooting tool, it is important to periodically check
protocol queues (for example, SMTP or X.400 queues) to ensure that no
delivery problems exist.
Details Templates Editor
The
Details Templates Editor is used to modify the graphical user interface
for document templates for contacts, users, groups, mailbox agents,
public folders, and search dialog boxes. When an organization wants to
modify the default templates to add a custom field, change the size or
type of an existing field, or modify the template form, it should use
the Details Templates Editor.
Active Directory Database Maintenance Using ntdsutil
Exchange
Server 2013 uses Windows Active Directory to store all its directory
information. As a result, it is important to keep AD as healthy as
possible to ensure that Exchange Server 2013 remains reliable and
stable.
Windows Server automatically
performs maintenance on Active Directory by cleaning up the AD database
on a daily basis. The process occurs on domain controllers
approximately every 12 hours. One example of the results of this
process is the removal of tombstones, which are the “markers” for
previously deleted objects. In addition, the process deletes
unnecessary log files and reclaims free space.
The
automatic daily process does not, however, perform all maintenance
necessary for a clean and healthy database. For example, the
maintenance process does not compress and defragment the Active
Directory database. To perform this function, the ntdsutil
command-line utility is needed.
Caution
To avoid possible adverse effects with the AD database, run ntdsutil
in Directory Service Restore mode. Reboot the server, press the F8 key, and then select this mode of operation.
To use ntdsutil
to defragment the Windows Active Directory database, perform the following steps:
1. Restart the domain controller.
2. When the initial screen appears, press the F8 key.
3. From the Windows Advanced Options menu, select Directory Services Restore Mode.
4. Select the Windows Server operating system being used.
5. Log on to the Windows Server system.
6. Click OK when the informational message appears.
7. At a command prompt, create a directory where the utility can store the defragmented file. For example, C:\NTDS
.
8. At a command prompt, type ntdsutil files, and then press Enter.
9. At the file maintenance prompt, type compact to <TargetDirectory>, where <TargetDirectory> identifies the empty directory created in step 7. For example:
compact to c:\ntds
This invokes the esentutl.exe
utility to compact the existing database and write the results to the specified directory.
10. If compaction was successful, copy the new ntds.dit
file to %systemroot%\NTDS
, and delete the old log files located in that directory.
11. Type quit twice to exit the utility.
12. Restart the domain controller.
This
typically needs to be done only following a large migration or
reorganization of the Active Directory forest, rather than on a routine
basis.
Database Maintenance with the eseutil Utility
The eseutil
utility is a database-level utility that is not application-specific.
It can, for example, be used to maintain, test, and repair both AD and
Exchange Server databases. More specifically, eseutil
is
used to maintain database-level integrity, perform defragmentation and
compaction, and repair even the most severely corrupt databases. It is
also the utility to use when maintaining Exchange Server 2013
transaction log files to determine which transaction logs need to be
replayed or which log file the Edb.chk
file points to.
Caution
Using the eseutil
utility on an AD or Exchange Server database can produce irreversible changes.
It is best to restore a copy of a suspected corrupt database in a lab environment, and then run eseutil
against that copy prior to any attempts to use it in a production environment.
Note
eseutil
investigates the data
that resides in the database table for any corruption or errors, which
is why it is called a database-level utility. The eseutil
options are shown in Table 1.
Table 1. eseutil Syntax
The eseutil
tool repairs the mailbox and public folder databases (database files, tables, and indexes), whereas the isinteg
tool repairs the contents of the mailbox and public folder databases (messages, links, and attachments).
Note
Because Exchange Server 2013 data is commonly
replicated using database availability groups (DAGs) and subsequent
copies of Exchange databases are available on the network, the eseutil
is not used that frequently anymore. While database corruption may
exist in one copy of the database, another copy of the organization’s
database may reside on another DAG copy without corruption. Eseutil
should only be used when other alternatives for database repair do not exist, and eseutil
is the last resort for data recovery.
Auditing the Environment
Various
methods of auditing the Exchange Server environment exist to gather and
store records of network and Exchange Server access and to assist with
the monitoring and tracking of SMTP connections and message routing.
Typically
used for identifying security breaches or suspicious activity, auditing
has the added benefit of allowing administrators to gain insight into
how the Exchange Server 2013 systems are accessed and, in some cases,
how they are performing.
This article focuses on three types of auditing:
• Audit logging—For security and tracking user access
• SMTP logging—For capturing SMTP conversations between messaging servers
• Message tracking—For tracking emails through the messaging environment
Audit Logging
In
a Windows environment, auditing is primarily considered to be an
identity and access control security technology that can be implemented
as part of an organization’s network security strategy. By collecting
and monitoring security-related events, administrators can track user
authentication and authorization, as well as access to various
directory services (including Exchange Server 2013 services).
Exchange
Server 2013 relies on the audit policies of the underlying operating
system for capturing information on user access and authorization.
Administrators can utilize the built-in Windows Server event auditing
to capture data that is written to the security log for review.
Enabling Event Auditing
Audit
policies are the basis for auditing events on Windows Server systems.
Administrators must be aware that, depending on the policies
configured, auditing might require a substantial amount of server
resources in addition to those supporting the primary function of the
server. On servers without adequate memory, processing power or hard
drive space, auditing can potentially result in decreased server
performance. After enabling auditing, administrators should monitor
server performance to ensure the server can handle the additional load.
To enable audit policies on a Windows Server 2008 or 2008 R2 server, perform the following steps:
1. On the server to be audited, log on as a member of the local Administrators group.
2. Select Start, Administrative Tools, and launch the Local Security Policy tool.
Note
For a Windows Server 2012 environment, press
the Windows key to bring up the Metro desktop menu, type local (which
will start to search for any application or utility that has the word
local in it), and choose the Local Security Policy tool.
3. Expand Local Policies and select Audit Policy.
4. In the right pane, double-click the policy to be modified.
5. Select to audit Success, Failure, or both.
6. Click OK to exit the configuration screen, and then close the Local Security Policy tool.
Figure 5 shows an example of typical auditing policies that might be configured for an Exchange server.
Figure 5. Windows Server 2008 audit policy setting example.
These
audit policies can be turned on manually by following the preceding
procedure, configuring a group policy, or by the implementation of
security templates.
Note
After enabling audit policies,
Windows event logs (specifically the security log) will capture a
significant amount of data. Be sure to increase the “maximum log size”
in the security log properties page. A best practice is to make the log
size large enough to contain at least a week’s worth of data, and
configure it to overwrite as necessary so that newer data is not
sacrificed at the expense of older data.
Viewing the Security Logs
The events generated by the Windows Server auditing policies can be viewed in the security log in the Event Viewer.
Understanding
the information presented in the security log events can be a
challenge. The event often contains error codes, with no explanation on
their meaning. Microsoft has taken strides to make this easier by
providing a link to the Microsoft Help and Support Center within the
event.
When an administrator clicks on the
link, the Event Viewer asks for permission to send information about
the event to Microsoft. Administrators can select the option to always
send information if they want, and can then click Yes to authorize the
sending of the data. A connection is made to the Help and Support
Center, and information about the Event ID is displayed. This
information can be invaluable when trying to decipher the sometimes
cryptic events in the security log.
Administrators
can use the Filter feature (from the View menu) to filter the events
based on various fields. In addition, when searching for a specific
event within a specific time frame, administrators can select a
specific window of time to filter on.
The
information supplied here on viewing security log Event IDs is intended
to help administrators get a basic understanding of the topic. There is
much more that can be learned on the subject of security auditing and
event monitoring, and the Microsoft website is an excellent resource
for doing so.