New book: Microsoft Windows Exchange Server 2010 Inside Out

We’re excited to announce that Microsoft Windows Exchange Server 2010 Inside Out , written by Tony Redmond (ISBN 9780735640610; 1248 pages) is now available for purchase!  

In today’s post, please read an excerpt from Chapter 6, “Managing Mail-Enabled Recipients,” which describes how to create mailboxes, groups, and contacts and discusses how to name mailboxes so that administrators and users alike can find the people with whom they want to communicate.

Chapter 6 - Managing Mail-Enabled Recipients

Now that we have mastered the tools that are available to manage Exchange, we can proceed to create some mailboxes, groups, and contacts and discuss how we might successfully manage these objects. A reasonable amount of change takes place in Microsoft Exchange Server 2010 in areas such as moderated recipients, but there are still some foundational topics that we need to review first. Let’s start by discussing how to name mailboxes so that administrators and users alike can find the people with whom they want to communicate.

Stop and think

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 these 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 a Simple Mail Transfer Protocol (SMTP) server. Applications do not need mailboxes for this purpose as they can create and submit messages to an SMTP server that supports submission from anonymous senders. The easiest way to support e-mail submission for applications is to use the transport pickup directory (see Chapter 13, “The Exchange Transport System”). 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. Once 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 the recently departed is probably useless after three months. Of course, there will be exceptions, including mailboxes belonging to executives,which might be needed should a discovery search be 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 (see Chapter 15, “Compliance”).

Note: Apart from anything else, old mailboxes and accounts could represent a security weakness that a hacker can exploit. Some companies move all mailboxes belonging to departed employees to a special database so that they are grouped together and are obviously different to “live” mailboxes.

• Audit mailboxes regularly. You don’t want to pay Microsoft any more for Client Access Licenses (CALs) than you should. CALs are 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 take a list of mailboxes in a database and report the last time that they were logged on to detect potentially unused mailboxes. For example, this command fetches details of all user mailboxes in a database and sorts them according to the last time a user logged onto 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 separates the most recent logon (my mailbox) and the oldest. It’s reasonable to suspect that the mailboxes that have not been accessed in two months are no longer needed.

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

DisplayName	LastLogonTime	ItemCount	Total ItemSize
Holm, Michael	5/20/2010 12:08:43 PM	81	170.3 MB (178,611,937 bytes)
Chen, Jacky	5/21/2010 10:46:29 AM	33	161 KB (164,888 bytes)
Palma, Tude	5/26/2010 4:23:28 PM	34	41.07 MB (43,064,720 bytes)
Ruth, Andy (Sales VP)	5/26/2010 5:24:37 PM	1089	145.9 MB (153,019,826 bytes)
Smith, Samantha	5/26/2010 5:40:33 PM	57	60.79 MB (63,744,292 bytes)

With these points in mind, we can proceed to create and manage some mailboxes.

Mailbox naming conventions

Although e-mail Address policies allow you to define and apply different patterns for SMTP addresses, Exchange 2010 does not provide policies to control the generation of display names, which is the attribute that Exchange uses to sort objects in the Global Address List (GAL) and Exchange Management Console (EMC) and also for recipients and authors in message headers.

Table 6-1 lists the different attributes for the various names or name components used by Exchange that are stored in the Active Directory directory service. 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 where 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, like 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, like 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 6-1 Mailbox attributes and names

EMC includes logic to respect locales so that name-related edit boxes are reordered to reflect language-specific naming conventions. The language that you use determines the fields that are exposed when you create new objects and the order in which the fields are used. For example, EMC doesn’t display the initials field in the French version. If you create users in the Chinese version, the boxes are presented by EMC in surname, initials, and first name order, which is exactly what some organizations that run everything in English would like to use. However, you can’t force this order to occur for other locales because the ordering is hard-coded in EMC.

INSIDE OUT Applying a different naming convention

Although the sequence used in naming conventions is hard-coded in EMC, it is possible to alter a convention. If you want to apply a different naming convention, the usual approach is to either:

· Allow EMC to create the mailboxes and contacts as normal and subsequently edit the Display Name.

· Create mailboxes and other mail-enabled recipients using shell scripts so that you have complete control over the format used for display names.

There mightbe other circumstances where you have mailboxes that 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 6-1 shows a GAL where the mailboxes use the Last Name, First Name convention. As you can see, some of the entries have additional information to identify individuals who share common names. It is common to use department names, locations, or job titles to help users identify the correct recipient.

Figure 6-1 A well-ordered 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 an individual recipient. The Exchange 2010 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 use “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 of 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 end up with names like “## Sales Executives”. This approach works but is not as user friendly as the other one.

Creating new mailboxes

Creating a new mailbox with EMC is easy. Click the new mailbox option and EMC launches the New Mailbox Wizard to gather the information that it needs to create the mailbox. Figure 6-2 shows the initial screen used by the wizard.

Exchange 2010 supports the following mailbox types:

· User mailboxes: The standard full-function mailboxes used by Exchange. EMC can create a mailbox in any database in the organization.

· Room mailboxes: Used to represent conference rooms so that users can book them for meetings through calendar requests.

· Resource mailboxes: Used to represent other items of equipment (such as projectors, communication equipment, or whiteboards) that users might need to reserve for a meeting.

· Linked mailboxes: Mailboxes that are linked to a user account in a separate, trusted forest.

The New Mailbox Wizard can create any of these mailbox types.

Figure 6-2 Creating a new mailbox with the EMC New Mailbox Wizard.

Integrating mailbox creation into overall company policy

Before plunging into the details of how to use the wizard to create a new mailbox, it’s important to recognize that creating a mailbox might be only one small part of a complete user on-boarding process that covers multiple activities including:

· HR provisioning: Allocation of employee number, creation of employee record in human resources (HR) system, generation of identity badge, application for corporate credit card, and so on.

· IT provisioning: Allowing access to operating systems (Windows might be only one of the operating systems used by the company),applications including e-mail and Web repositories or document management systems, allocation of mobile devices, provision of security tokens or keys necessary to allow virtual private network (VPN) access to the company network from the Internet.

· Facilities provisioning: Assigning office space and physical items required by the employee, including PC and printer.

Many large companies operate sophisticated workflow applications that take care of many of these activities. A similar workflow is usually present to remove access and “deprovision” an employee who leaves the company. Because the on-boarding process can be so complicated and require interaction with so many different applications, it’s wise to consider how you will integrate the creation of an Exchange mailbox into the process. For example, will you build a step into the workflow to create a mailbox automatically and have the characteristics of the mailbox (quota, personal archive, retention policy) set automatically depending on the employee’s level and job code, or will you have a request generated and sent by e-mail to the help desk?

The most common problems encountered by administrators when they attempt to create mailboxes with EMC’s New Mailbox Wizard are the following:

· Failure to provide a unique alias or UPN: The wizard does not check whether the values assigned to the alias or UPN have already been used by an existing Active Directory object until it attempts to create the new mailbox, at which time you’ll see an error similar to that shown in Figure 6-3. The management consoles in Exchange Server 2003 and Exchange Server 2007 both populate the alias field with a suggested value determined through a background call to Active Directory. For some reason, the security model used by Exchange 2010 forced Microsoft to remove this call to result so the administrator has to determine a unique alias. Fixing the problem is easy for an administrator—simply go back through the screens and input a unique alias—but it can be frustrating to do this because it’s impossible to know what a unique alias might be unless you check Active Directory first. Your company might have rules that determine how to create new aliases that help you figure out what the value should be. Note

The problem doesn’t exist in Exchange 2010 SP1 because Microsoft includes code in the New Mailbox Wizard to calculate a unique alias based on the name properties of the mailbox. However, you may still want to adjust the alias automatically generated by the wizard to satisfy naming guidelines.

Figure 6-3 Error in mailbox creation:Duplicate UPN detected .

· Failure to provide a password for a new account that meets Windows requirements: If you input a password that does not meet the policy implemented for Windows (for example, it contains the name of the user), the wizard will not be able to create the new account when it attempts to create the new mailbox.

· Inadvertent selection of features that require an enterprise CAL: Features such as managed folder policies and archive mailboxes increase the number of enterprise CALs that your organization requires. The wizard indicates that these features require enterprise CALs but it’s easy to miss the warnings (or not understand the consequences of opting for the feature;not every administrator understands the cost difference between standard and enterprise CALs).Unlike the other cases, selecting a feature that requires an enterprise CAL does not prevent the mailbox being created.

Using a wizard is great if you have only a few mailboxes to create. Once the load increases, it’s time to master the intricacies of the cmdlets that are used, especially if you need to integrate mailbox creation with another process, such as that used by the HR department to introduce a new employee to the company. As in many cases, the code generated by EMC to perform an action is a good starting point. The code necessary to create a new mailbox with a new Windows account is shown next. Table 6-2 lists the most common parameters to use when creating a new user mailbox complete with a Windows account. As you will see later on, other types such as room and equipment mailboxes use different parameters:

New-Mailbox -Name 'Eoin P. Redmond' -Alias 'epr' -UserPrincipalName 'epr@contoso.com' -SamAccountName 'epr' -FirstName 'Eoin' -Initials 'P' -LastName 'Redmond' -Password 'System.Security.SecureString' -ResetPasswordOnNextLogon $True -Database ‘DB1'

Because this code was copied from EMC, it contains ‘System.Security.SecureString’ for the password value. If you create a script to create new mailboxes, you can use the ConvertTo-SecureString cmdlet to convert a predetermined value into a suitable secure string for the password. For example:

-Password (ConvertTo-SecureString ‘Exchange2010!’ –AsPlainText –Force)

Creating a mailbox is only the start of the process to build out a mailbox that is fully ready to use. The code that you’ve just looked at doesn’t exploit the ability to assign special mailbox quotas, set up moderation for the mailbox, apply ActiveSync or Outlook Web App (OWA) policies, or create an archive mailbox. All of these settings can be enforced as you create the new mailbox with the New-Mailbox cmdlet or immediately afterward with the Set-Mailbox cmdlet. In addition, Exchange 2010 provides a new set of cmdlets to manipulate settings such as language and regional settings, and autoreply and calendar settings. See the section “Manipulating mailbox settings” later in this chapter for more information on this topic.

Table 6-2 Properties used to create a new mailbox with New-Mailbox

If you select the option to create a mailbox for a Windows account that already exists, EMC uses the Enable-Mailbox cmdlet to create a new mailbox and associate it with the Windows account that you select. The code is much simpler because the Windows account already has many established properties that you’d otherwise have to provide. All you need to state for the new mailbox is an identity, an alias, and a target database. For example:

Enable-Mailbox -Identity ‘contoso.com/Exchange Mailboxes/Akers,Kim’ -Alias 'KAkers'
-Database 'DB2'

Immediately after the new mailbox is created, Exchange applies the appropriate e-mail address policy to create suitable e-mail addresses for the mailbox and updates Active Directory with these values. See the section “E-mail address policies” later in this chapter for more information about how to create e-mail address policies.