When a new version of Microsoft Exchange Server appears, administrators are often excited by its new features, but users are typically often left cold because they see no value from those features. However, MailTips is a new feature in Exchange Server 2010 that delivers real value to users, providing they use a client that supports MailTips, which is currently Microsoft Outlook 2010 and Outlook Web App (OWA) 2010. The idea behind MailTips is to provide users with immediate feedback to help users save time and help IT save system resources. The value of this idea is so obvious that it's surprising that it took so long for this feature to appear. After I explain why MailTips are valuable and how they work, I'll show you how to configure them.
Taking a Proactive Stance
In early email systems, sending a message was a "send and forget" affair. You dispatched a message into the void and hoped that it arrived. As time went by, features such as out-of-office notices, delivery and read receipts, and nondelivery notifications were incorporated to give users feedback as to what happened to messages after they were sent. Exchange 2010 introduces a variation on the theme with a feature called delivery reports that lets users see the path of a message within an Exchange organization, including the expansion of distribution groups into individual members, delivery to servers, and delivery to external connectors for transmission to other email systems. However, worthy as these features are, they're 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 the message wasn't delivered.
Enter MailTips, a new web service designed to provide users with feedback about common problems before a message is sent. The idea is that by being proactive and warning users that messages might not be delivered or read, users will be more productive and less likely to call the Help desk to complain that their email didn't arrive. Plus, MailTips can reduce system resource usage by eliminating the need to process messages that will fail.
Table 1 lists some common conditions when MailTips are useful.
|
Potential Problem |
Action |
|
Message addressed to recipient that's out of the office |
If an out-of-office notice is set for a mailbox, the user is told that the recipient is away and has the choice to remove that person from the message. MailTips displays the first 250 characters of an out-of-office notice. |
|
Message addressed to a very large distribution |
If a message is addressed to a distribution that has more recipients than the large-audience limit configured for the organization, MailTips tells the user how many people will receive the message (per group and in total). Duplicate addressees aren't removed, so the overall total might be a little higher than the actual number of messages that are generated, but it's a good guide to stop users from sending messages that result in hundreds of deliveries. Exchange doesn't attempt to process individual MailTips for messages that are addressed to more than 200 recipients, as this would impose an unacceptable performance overhead on the CAS server. For the same reason, when a user addresses a message to a distribution group, Exchange doesn't evaluate individual MailTips for the group members. The exception is that Exchange will show the number of external recipients if there are any in the group. |
|
Message addressed to a non-existent recipient |
Messages can linger in mailboxes for a long time and might contain addresses that are no longer valid. Invalid addresses can also persist in Outlook's auto-complete list. MailTips detects this condition and lets the user remove the obsolete recipient before sending the message, thereby eliminating a nondelivery notification. |
|
Message addressed to an external recipient |
If a message is addressed to someone outside the organization or a group that contains an external recipient, MailTips warns the user in case the message contains confidential company information. |
|
Reply to Bcc |
If users reply to a message in which they're on the Bcc list, MailTips notifies them about being blindly copied and lets them know that if they reply, the other recipients will know they received the original message. |
|
Oversized message |
If users attempt to send a message that exceeds the maximum message size for the organization or for one of the message recipients, MailTips tells them that Exchange won't deliver the message. MailTips can't warn users that an external organization will have problems with an oversized message. |
|
Message addressed to a moderated group |
Messages sent to a moderated group have to be approved by the moderator, so MailTips warns the user that there might be a delay before the message is okayed. Moderators of the group or anyone explicitly allowed to receive messages addressed to the group won't see this MailTip. |
|
Message addressed to a restricted recipient |
Administrators can configure mailboxes and groups so that only certain users can send them messages. If unauthorized users attempt to send a message to a restricted recipient, MailTips warns them that their message won't be accepted. |
As you can see, in most cases, MailTips stop users from doing something that wastes time and causes frustration or something that reduces traffic for Exchange. Warning users about sending a message to a very large distribution is useful because they often don't realize that it will cause Exchange to deliver the message to thousands of mailboxes. People who receive the message can cause a mail storm by using Reply to All to generate a response that goes to everyone and provokes even more responses. The net result is usually a Hub Transport server that's swamped with traffic, large message queues, and slow delivery of other mail.
How MailTips Work
MailTips operate on a mixture of data originating from:
- Active Directory (AD). For example, AD provides information about whether a recipient is restricted or about the maximum size of attachments.
- The Information Store. For example, the Store provides information about mailbox quotas, out-of-office notices, and custom MailTips.
- Exchange 2010's Group Metrics service. For example, Exchange 2010's Group Metrics service provides information about the total number of recipients in a group or the number of external recipients in a group.
The group metrics data is stored in a cache on Exchange 2010 Client Access Server (CAS) servers. When MailTips are configured for an organization, the Group Metrics service automatically runs on every mailbox server that generates an Offline Address Book (OAB), counting the number of recipients in every group, including dynamic distribution groups. The Group Metrics service runs every Sunday. (Unfortunately, you can't change the day that this operation occurs.) On the other days of the week, the service generates incremental data on groups that have been added or changed. The reason why this happens on OAB servers is that some MailTips data, such as the number of recipients in a group, is distributed with the OAB, so it's necessary to generate the data before it can be included in the OAB.
Exchange distributes the group metrics data from the OAB servers to CAS servers every eight hours using the Exchange File Distribution service. This arrangement ensures that the CAS servers have recent data and that a client can connect to a local CAS server to fetch MailTips data.
MailTips-enabled clients request data using a background thread when a user adds a recipient or attachment to a message or uses the Reply or Reply to All button to respond to a message. MailTips are also processed when a draft message is opened. These actions cause the client to query the MailTips web service on a CAS server in the local site to determine whether there are any MailTips that apply to the message. The CAS server first gathers data from AD and the local group-metric cache, then responds to the client with applicable data. It also contacts the mailbox servers that host recipient mailboxes to fetch information about mailbox quotas and out-of-office notices. If some of the mailbox servers are outside the local site, the CAS proxies a request to fetch the data to a CAS server running in the site that hosts the mailboxes. To avoid unacceptable delays, the request will time out and the client will proceed without MailTip data if the CAS server is unable to respond to clients within 10 seconds.
To limit the amount of communication with the CAS server, Outlook and OWA 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 will check its cache to discover if it exceeds the maximum message size for the organization. If the data isn't in the cache, the client retrieves it from the appropriate source (in this case, Exchange configuration data in AD) and caches it locally for future reference. Cached information is removed from the cache after 24 hours, with the exception of mailbox-full and out-of-office notices, which are removed after 2 hours because they typically change more often. Client-side caches aren't persistent and are cleared whenever users exit Outlook or OWA.
Configuring MailTips
From an administrator perspective, the immediate value of MailTips is that they eliminate many of the reasons why Exchange has to generate nondelivery reports (e.g., destination mailbox is full, message size too large), which reduces some 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 at an increase of approximately 5 percent. Exchange administrators can configure MailTips on or off, but only at the organization level by using Windows PowerShell's Set-OrganizationConfig cmdlet to set the parameters that control MailTips processing. This cmdlet's parameters are:
- 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; any other domain 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, where big distribution groups are common. In this scenario, it makes sense to increase the value to 50 to stop MailTips from nagging users for no good reason.
- MailTipsMailboxSourcedTipsEnabled. Controls whether MailTips that depend on mailbox data such as out-of-office notices are enabled. The default is $True.
Figure 1 shows what a user might see when you configure MailTips.
In this case, two conditions have been detected. First, the number of recipients in the message header exceeds the configured large-audience threshold. The recipient count includes the individual addressee for the Central Help Desk. Second, a custom MailTip is displayed for a group to inform the user that he or she should really log a call with the Central Help Desk website. (I'll show you how to create a hyperlink in a MailTip shortly)
Outlook users have the ability to configure the MailTips they see in mail headers. As Figure 2 shows, the user can select the types of MailTips to display, whether to have the MailTips bar available at all times, and whether to automatically expand the MailTips bar if multiple tips are available.
OWA doesn't include any UI to configure MailTips, and you can't manipulate client-side MailTip settings through Exchange Management Console (EMC) or Exchange Management Shell (EMS).
Custom MailTips
You can add a custom MailTip to any mail-enabled object. Most often this is done for:
- Mailboxes that aren't monitored in order to notify users that their messages might not be responded to quickly
- Moderated addresses
- Restricted distribution groups (including dynamic groups) that don't accept messages from users who aren't on an approved list
- Special mailboxes (e.g., mailboxes used by Help desks) to provide guidance to users or to set expectations about when the user might expect a response.
Custom MailTips can be up to 250 characters. They're configured the same way as any other property for a mail-enabled object. For example, to create a custom MailTip for a mailbox, you use the Set-Mailbox cmdlet in a command such as
Set-Mailbox -id 'Help Desk' -MailTip 'Messages to the Help Desk are handled on a best-effort basis; please call 91184 if you need urgent support'
(Although this command wraps here, you'd enter it all on one line in the PowerShell console. The same holds true for the other commands that wrap.) You use the same approach for a distribution group:
Set-DistributionGroup -id 'Sales' -MailTip 'Only members of the Sales Executives group can send to this address'
MailTips support HTML content, which is useful when you want to include a URL that points users to more information. For example, messages sent to a Help desk might include a URL that points users to a website where they can log a support call:
Set-Mailbox -id 'Help Desk' -MailTip 'Please visit the Help Desk site to log a support call.'
You can't edit a custom MailTip. Instead, you overwrite it with new text. Exchange 2010 only supports simple text in a custom MailTip, which means you can't incorporate any form of rule to control when a client might display the MailTip. For example, you can't create a MailTip that scans the message text for a matching pattern such an ID number or even a simple term such as the name of a project. It wouldn't be surprising if Microsoft introduced rule-based processing capabilities for MailTips in a future version of Exchange.
MailTips are stored as properties of the mailbox in AD. The CAS server reads the data hourly so any change that you make to a custom MailTip can take up to an hour before it goes into effect. The only way to force a change so that the MailTip goes into effect sooner is to recycle IIS, which is difficult in a production environment.
Custom Multilingual MailTips
Exchange 2010 accommodates the need of multilingual organizations by letting you create custom MailTips in all the languages you need to support. This is a little more complex than setting a simple MailTip in one language. You need to first determine the list of languages, translate the string into appropriate text for each language, and populate the array of translations using the -MailTipTranslations parameter for each of the Set-Mailbox, Set-DistributionGroup, Set-Contact, and Set-MailPublicFolder cmdlets as required. You have to create a default MailTip before you can add the translated values. Here's an example of what the code might look like:
Set-Mailbox -id 'Ben Geerdes' -MailTip 'Happy Holidays' -MailTipTranslations 'NL: Gelukkihe Vakantie', 'IT: Feste Felici', 'FR: Bon Vacances'
The default value is used whenever a user's language doesn't match a specific value in the list. If you'd use PowerShell to look at a mailbox's MailTipTranslations property after you run the code, you'd see all of the different language strings listed in the order that they were entered, as Figure 3 shows.
A Proactive Feature
MailTips truly are a proactive feature to help users work more effectively with email. Although MailTips won't remove the need for user intelligence, they can give users helpful hints at the most appropriate time—before they send the message. MailTips are easy to configure and maintain, even if you don't like using PowerShell. All in all, the only problem with MailTips is that most companies won't be able to take advantage of them until they deploy Exchange 2010 (including OWA) and Outlook 2010.
