All of us have stories about an unbelievable but all too
common mistake we have made with email. Maybe you sent a message to the
wrong user containing sensitive or other information that she shouldn’t
have received, or maybe you answered a note on which you were
blind–carbon copied and caused the original sender trouble when the
other recipients realized that you were copied. Microsoft refers to
situations like this as “unfortunate messaging scenarios,” whereas
administrators might use slightly more robust terms to describe the
result of user mistakes that cause system performance to suffer, mail
queues to accumulate, or lots of calls to flow in to the help desk.
It’s unfortunate, but humans make mistakes all the time.
Early
email systems operated on a simple “send and forget” principle. You
dispatched messages into the void and hoped that they’d arrive. As time
went by, features such as out-of-office notices (OOF), delivery and
read receipts, and nondelivery notifications were incorporated to give
users feedback about what happened to messages after they were sent.
Exchange 2010 introduced delivery reports, which enable users to see
the path of a message within an Exchange organization, including the
expansion of distribution groups into individual members to receive the
message, delivery to servers, and delivery to external connectors for
transmission to other email systems. However, worthy as these features
are, they are all after the fact. Messages have to be sent before users
can be informed that the message has been delivered, that someone is
out of the office, or that their email won’t be delivered because a
recipient’s mailbox quota is exceeded.
MailTips are designed to
provide users with feedback about common problems before a message is
sent. The idea is that warning users that messages might not be
delivered or read will make users more productive and less likely to
call the help desk to complain that their emails didn’t arrive. It will
also reduce system resource usage by eliminating the need to process
messages that will fail. Microsoft hopes that MailTips will help people
use email more intelligently. The feature is supported by Outlook Web
App (including Outlook Web App for Devices) and Outlook 2010 or Outlook
2013 when connected to an Exchange 2010 or Exchange 2013 mailbox. Quite
logically, MailTips won’t work when Outlook is not connected to
Exchange.
MailTips operate on a mixture of data originating from the following sources:
Active Directory (for example, whether a recipient is restricted, the maximum size of attachments supported by the organization)
Information Store (mailbox quotas, out-of-office notices, custom MailTips)
Group
metrics (metadata generated for the total number of recipients in a
group and the number of external recipients in a group)
Group
metrics information is stored in the group object in Active Directory
in the msExchGroupMemberCount (number of members in the group) and
msExchGroupExternalMemberCount (number of external recipients in the
group) and is calculated for both normal and dynamic groups. Figure 1
shows the properties of a group as viewed through ADSIEdit with both
the external count (0) and member count (82) clearly visible. Using
Active Directory to hold group metric data is a change from Exchange
2010, which instead uses a cache on the CAS.
The
Group Metrics mailbox assistant runs on every Mailbox server that is
configured to generate group metrics data to count the number of
recipients in every group in the organization, including dynamic
distribution groups. On the basis that user workload is light during
the weekend, Exchange 2010 servers generate group metrics data on a
Sunday. Exchange 2013 uses the work cycle approach that’s seen in other
mailbox assistants to run daily at a time when system workload is light
and its activity will not affect users. If system workload increases
when the Group Metrics mailbox assistant is active, it throttles back
and waits until the workload eases. If a server is under consistently
high load over a complete day, the generation of group metrics data
will be delayed. However, given that only a few groups might be added
or have their membership updated during this period, the overall effect
on the accuracy of the data shown to users through MailTips is limited.
By
default, every Mailbox server that generates the OAB also generates
group metrics data. OAB servers generate group metrics data because the
OAB reuses some MailTips data (including group metrics), so it’s
necessary to generate the data before it can be included in the OAB.
To discover which servers generate group metrics data, run this command:
Get-MailboxServer | Select Name, ForceGroupMetricsGeneration
Any
server that reports True for ForceGroupMetricsGeneration is configured
to generate group metrics. You can configure other Mailbox servers to
generate group metrics by running the command. Normally, this isn’t
necessary, but it is conceivable that you want to spread the generation
load across the organization.
Set-MailboxServer –Identity ExServer1 –ForceGroupMetricsGeneration $True
On
the other days of the week, the service generates incremental data for
the number of recipients in groups that have been added or changed.
Event 14034 is logged under the MailTips category when a server begins
to process group metrics data. If you examine these event entries, you
can find out how many groups were processed and whether the run was the
weekly full scan or a daily delta.
The \Exchange Server\V15\GroupMetrics directory on a Mailbox server holds the files used for group metrics. These are:
A
cookie file with a .dsc extension that contains information to identify
the Mailbox server that generates the group metrics data and the date
and time when the data was last successfully updated. By comparing the
date and time held in this file with the current date and time and the
last changed time stamp on group objects, Exchange knows which groups
it has to process to derive updated group metrics data.
A
simple text file called ChangedGroups.txt. After a successful update of
group metrics data, the ChangedGroups.txt lists any group that Exchange
processed. It is a simple list of the distinguished name for each
group. For example:
CN=Dublin Users,OU=Exchange groups,DC=contoso,DC=com
When
Exchange generates group metrics data, it first identifies the set of
changed groups and then counts the number of recipients in each one of
these groups. The resulting count is then written into the properties
of the group in Active Directory.
MailTips-enabled clients request data when a user adds a
recipient or attachment to a message or uses the reply or reply all
command to respond to a message. MailTips are also processed when a
draft message is opened. These actions cause the client to invoke a
background thread to query the MailTips web service on a CAS server on
the local site and determine whether any MailTips apply to the message.
The URL for the MailTips web service is returned by the CAS server to
the client as part of the Autodiscover manifest.
The CAS server
is responsible for gathering data from Active Directory and the local
group metrics cache and responding with applicable data to the client.
It also contacts the Mailbox servers that host recipient mailboxes to
fetch information about mailbox quotas and OOF notices. If some of the
Mailbox servers are outside the local site, the CAS proxies a request
to fetch the data to a Mailbox server running on the site that hosts
the mailboxes.
Note
To
avoid unacceptably slow responsiveness, if the Mailbox server is unable
to respond to clients within 10 seconds, the request times out, and the
client proceeds without MailTip data. It’s also important to say that
you do not have to wait for MailTips processing to finish before you
can send a message. If MailTips hasn’t responded and you need to get
the message to its recipients, you can click Send, and the message will
go without further notice.
To limit the amount of
communication with the CAS, Outlook and Outlook Web App clients both
maintain client-side caches that are populated as messages are
processed. For example, if you attempt to send a message containing a
very large attachment, the client checks its cache to discover whether
it exceeds the maximum message size for the organization. If the data
are not in the cache, the client retrieves them from the appropriate
source (in this case, Exchange configuration data in Active Directory)
and caches it locally for future reference. Cached information is aged
out of the cache after 24 hours with the exception of mailbox full and
OOF notices, which are likely to change more often and therefore age
out after two hours. The MailTips settings used for Outlook Web App are
contained in the Web.config.xml configuration file. It is possible, but
not recommended, to change the cache aging limit and the number of
items held in the cache by editing this file. Client-side caches are
not persistent and are cleared whenever you exit Outlook or Outlook Web
App.
From an administrator perspective, the immediate value of
MailTips is that they eliminate many of the reasons Exchange has to
generate nondelivery reports (for example, destination mailbox is full,
message size too large) and so reduce the strain on the messaging
infrastructure. On the downside, the processing required to service
client requests for MailTip data creates an extra load on CAS servers,
which Microsoft characterizes as an increase of approximately 5 percent.
All
the management for MailTips is done through EMS. Exchange
administrators can configure MailTips on or off, but only at the
organization level, by using the Set-OrganizationConfig cmdlet to set
the parameters that control MailTips processing. These parameters are
as follows:
MailTipsAllTipsEnabled. Controls whether MailTips are enabled. The default is $True.
MailTipsExternalRecipientTipsEnabled. Controls
whether MailTips for external recipients are enabled. The default is
$False. External recipients are determined by reference to the accepted
domains list. Any domain in this list is deemed internal, whereas any
other is deemed external.
MailTipsGroupMetricsEnabled. Controls whether MailTips that depend on group sizes are enabled. The default is $True.
MailTipsLargeAudienceThreshold. Controls
the threshold for the number of recipients on a message before MailTips
flags it as large. The default value is 25. This value is probably too
low for large organizations in which big distribution groups are
common. In this scenario, it makes sense to increase the value to 50 to
stop MailTips from nagging users.
MailTipsMailboxSourcedTipsEnabled. Controls whether MailTips that depend on mailbox data such as OOF notices are enabled. The default is $True.
In most cases, a
MailTip stops a user from doing something that causes frustration (the
user’s message doesn’t get through) or reduces traffic for Exchange
(removing the need for nondelivery notifications caused by messages
that cannot be processed). Warning users about sending to very large
distribution lists is useful because it is too easy for a user to
address a note to a distribution that she doesn’t realize will cause
Exchange to deliver the message to thousands of mailboxes. People who
receive the message can cause a mail storm by using Reply All to
generate a response that goes to everyone and provokes even more
responses. The net result is usually mailbox servers that are swamped
with traffic, the accumulation of large message queues, and slow
delivery of other mail. MailTips won’t remove the need for user
intelligence, but they can give a hint at appropriate times to stop
someone from doing something he wishes he hadn’t.
