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:
Applications
don’t need mailboxes. Some administrators assume that it is a good
thing to assign mailboxes for use by applications that need to create
and send messages, usually by submitting a text message to an SMTP
server. Applications do not need mailboxes for this purpose because
they can create and submit messages to an SMTP server that supports
submission from anonymous senders. The easiest way to support email
submission for applications is to use the transport pickup directory.
If you do create mailboxes for application use, make sure that you
secure the accounts associated with the mailbox so that they are
restricted.
Mailboxes have
different types for a reason. Although it might seem fine to use normal
mailboxes for resources (rooms and equipment), Exchange has a purpose
behind the differentiation that it supports across mailbox types.
Resource mailboxes are tied to disabled Windows accounts, and user
mailboxes are not. Site mailboxes also use disabled Windows accounts.
When you start to use normal mailboxes for resources, you create a
potential security issue. Always assign the right mailbox type when you
create a mailbox.
Mailboxes
shouldn’t be kept forever. The information in a mailbox belonging to
someone who leaves the company is probably of some interest, but
interest wanes over time, and the information contained in most
mailboxes belonging to an employee who has recently left is probably
useless after three months. There will be exceptions, including
mailboxes belonging to executives, which might be needed if an
eDiscovery search is required for local information to respond to a
legal action. Nevertheless, you should agree on guidelines to govern
when mailboxes can be removed and make sure that old mailboxes and old
Windows accounts don’t linger past their best-by date.
Note
Apart
from anything else, old mailboxes and accounts could represent a
security weakness that an attacker can exploit. Some companies move all
mailboxes belonging to departed employees to a special database so that
they are grouped and are obviously different from live mailboxes.
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.
Table 1. Mailbox attributes and names
Attribute | Meaning |
---|
Alias | Unique name for the object |
Name | Full name of the object composed of first name and last name |
FirstName | First name of the user |
LastName | Surname of the user |
DisplayName | Name used to sort the GAL and for other display purposes (such as EAC and in message headers) |
DistinguishedName | Name used to identify object in Active Directory |
PrimarySMTPAddress | Primary SMTP email address (often first name.last name@domain) |
UPN | User
Principal Name, or the name of a user in email format that can be used
to log on to a Windows server; recommended that the UPN has same value
as the primary SMTP email address |
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.
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:
Smith, John (Corporate Acquisitions)
Smith, John (IT Standards)
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.