The need for mailboxes

Although it might be nice to be able to boast about the sheer scale of the organization you manage when you meet your peers at events such as the Microsoft Exchange Conference, managing a successful Exchange deployment is not determined by the number of mailboxes in the organization. Before you rush to create any mailboxes, you should lay out some guidelines for when mailboxes are created and when they are removed. Best practice for mailbox maintenance includes the following important points:

Audit mailboxes regularly. You don’t want to pay Microsoft any more for Client Access Licenses (CALs) than you should. CALs are often calculated on the basis of mailbox numbers, so it follows that keeping unnecessary mailboxes costs money. You should audit the mailboxes that exist in the organization at least every six months and remove any unused mailboxes. It’s easy to report the last time a list of mailboxes in a database were logged on to detect potentially unused mailboxes. For example, the following command fetches details of all user mailboxes in a database and sorts them according to the last time a user logged on to the mailbox. Users who have never logged on to their mailbox are indicated by an error when Get-MailboxStatistics attempts to retrieve information from the mailbox. Other information that might indicate an unused mailbox, such as the total number of items in the mailbox, is also included. This report shows that approximately two months separate the most recent logon (my mailbox) from the oldest. It’s reasonable to suspect that the mailboxes that have not been accessed in two months are no longer needed, or at least that they can be marked as being suitable for potential deletion if not required for regulatory purposes.

Get-Mailbox –Database DB2 –RecipientTypeDetails UserMailbox | Get-MailboxStatistics
 | Sort-Object LastLogonTime | Format-Table DisplayName, LastLogonTime, ItemCount, TotalItemSize

With these points in mind, you can create and manage some mailboxes.

Naming mailboxes

Email address policies enable you to define and apply different patterns for the SMTP addresses that are assigned to mail-enabled objects. The application of address policies makes sure that the SMTP addresses are consistent throughout the organization. Exchange 2013, unfortunately, does not provide a mechanism to control the generation of display names, which is the attribute that Exchange uses to sort objects in the GAL and EAC and for recipients and authors in message headers.

Table 1 lists the different attributes for the various names or name components Exchange uses that are stored in Active Directory. The default pattern for display names is %g %s; in other words, first name<space>last name or, in my case, Tony Redmond. This is an acceptable naming convention for small implementations in which everyone knows everyone else, and it is easy to find the correct recipient by browsing the GAL, but it becomes increasingly difficult to find people as the number of directory entries increases. The question, therefore, is what naming convention to use that is efficient and logical for users when they search for an object in the GAL. More variation occurs in surnames than in given names. Common given names, such as John or Mary, occur thousands of times in a large GAL, so if the GAL is sorted by given name, you might have a tiresome search before you locate the right recipient. It is easier to search using a surname, even with common surnames such as Smith, Chan, or Ng. Telephone directories are organized by surname, so it makes sense to carry the analogy forward and do the same thing for the GAL.

There might be other circumstances in which you have mailboxes for which you don’t want to use the last name, first name convention, such as those used for discovery results, but these can be dealt with on an exception basis. Figure 1 shows how Microsoft Outlook 2013 displays a GAL in which the mailboxes are organized using the last name, first name convention. As you can see, some of the entries have additional information to identify individuals who share common names or who have particular functions within the company. It is common to use department names, locations, or job titles to help users identify the correct recipient.

Figure 1. A well-ordered GAL

One problem with adding some detail to display names that deserves consideration is that it might expose some confidential information outside the company. For instance, assume that you have two people named John Smith in the organization, and you want to help users locate the correct person in the GAL, so you create display names that identify the two individuals by adding the department in which they work in parentheses. Thus, you might have:

These names help users know which of the two John Smiths to whom they should address messages. However, the issue arises when the names of the departments are also communicated to recipients outside the organization. Anyone who receives a message from either John Smith will know for which department he works. This might not be important for generic departments such as Sales or Marketing or locations such as Dublin or New York, but it could be for departments such as Corporate Acquisitions or Talent Management, both terms that convey a lot about the role the user holds within the company. The lesson here is that you need to think about whether it matters if people outside your company know the information you add to display names to identify people in the GAL.

Some companies like to impose a special naming convention for distribution groups so that users know when they are sending a message to a group rather than to an individual recipient. The Exchange MailTips feature helps here; it can either warn users when they address a message to a large group or display a tailored tip to indicate the purpose of the group. One solution is to prefix groups with some characters. For example, you could create a group naming policy, DG, as a prefix so that your groups would have names such as DG: Sales Executives and DG: IT Department. The advantage of this approach is that all the groups are found in a single location in the GAL. Some take the idea further and use a prefix such as ## that places all groups at the start of the GAL. You then have names such as ## Sales Executives. This approach works but is not as user friendly as the other one.