Every Microsoft Exchange Server or Exchange Online administrator knows about regular mailboxes. But how many know that they can add shared mailboxes to their deployment, at no cost? Making effective use of shared mailboxes can add a great deal of value, whether in an on-premises Exchange Server organization or a Microsoft Office 365 tenant domain. (See also, "Multi-Mailbox Search in Exchange Server 2010.")

What Is a Shared Mailbox?

As defined in the Microsoft article "Understanding Recipients," an Exchange shared mailbox isn't associated with a primary user. Rather, this type of mailbox is "generally configured to allow logon access for multiple users." In other words, a shared mailbox is a functional mailbox that one or more users access for a specific purpose. 

For example, suppose you ran a doctor's office. You could have a shared mailbox called Appointments, which you could use to send appointment reminders to patients (rather than sending the messages from the doctor's personal mailbox). In the same way, a consulting company such as mine could have a shared mailbox called Billing or Invoices, used to dispatch invoices to customers. In these scenarios, the users who have access to the shared mailboxes are called delegates. Before these users can work with the shared mailboxes, an administrator must delegate the rights to access and send mail by using those mailboxes.

Unlike regular mailboxes, users cannot log on to shared mailboxes because the Active Directory (AD) accounts that link to these mailboxes are disabled. Office 365 customers don't need to buy subscriptions for shared mailboxes, and on-premises Exchange customers don't need CALs to use shared mailboxes. However, in both instances, the delegates who access the mailboxes must be properly licensed. Apart from the licensing and logon differences, shared mailboxes work in the same way as regular mailboxes. You can assign an archive mailbox or apply a retention policy to a shared mailbox. See the Microsoft Exchange Licensing FAQ for additional details about licensing for shared mailboxes. 

Creating a Shared Mailbox

The version of the Exchange Control Panel (ECP) that is provided for Office 365 tenants doesn't support the creation of shared mailboxes. Luckily, you can easily use the Exchange Management Shell (EMS) for this purpose. I recommend that you follow the steps in MVP Brian Desmond's blog to create a Windows PowerShell profile that contains a function that does all the work of setting up a new remote management session with Office 365. 

After you're connected to Office 365, you can run the following steps to create the new shared mailbox and to configure it so that users can open it and send email from it. You will need to be a member of the Organization Management or Recipient Management role group to run these cmdlets:

  1. Run the New-Mailbox cmdlet to create the shared mailbox. Make sure to pass the -Shared parameter to mark the mailbox as shared. The only other parameter that you need to pass is the name of the shared mailbox. 
  2. Run the Add-MailboxPermission cmdlet to delegate the FullAccess right to the mailboxes that you want to access the shared mailbox. This delegation allows the mailbox users to open the shared mailbox via Microsoft Outlook or Outlook Web App (OWA). You can also grant access to a Distribution Group (DG); all the members of the group inherit the access. 
  3. Run the Add-RecipientPermission cmdlet to assign the SendAs right to users who you want to be able to send new messages from the shared mailbox. This cmdlet is unique to Office 365; in Exchange 2010, use the Add-MailboxPermission cmdlet to complete this task. 
  4. If you need an archive for the shared mailbox, run the Enable-Mailbox cmdlet for the mailbox and include the -Archive parameter. 

You can perform steps 2, 3, and 4 by using Exchange Management Console (EMC) wizards if you run a hybrid on-premises/cloud Exchange organization.

Figure 1 illustrates the steps to create a new shared mailbox named Billing: assigning FullAccess and SendAs rights to my mailbox. After the new shared mailbox is created, you can manage it through ECP, as if it was a typical mailbox. For example, you can edit the properties of the shared mailbox to add details such as the department.

Figure 1: Using PowerShell to add a new shared mailbox to Office 365

Accessing a Shared Mailbox

If you use Outlook 2010 or 2007, you don't need to do anything to access a shared mailbox after the FullAccess right is assigned to you. The next time that the Autodiscover function runs, it will detect that your mailbox can open the shared mailbox and will provide Outlook with the mailbox details. Microsoft made a change to Autodiscover, called auto-mapping, in Exchange 2010 Service Pack 1 (SP1) and further tweaked it in Exchange 2010 SP2. This change allows an administrator to provide a new, optional parameter to the Add-MailboxPermission cmdlet to tell Autodiscover not to map a shared mailbox for Outlook. Office 365 doesn't support earlier Outlook versions, but you can connect an Outlook 2003 mailbox to a shared mailbox on an Exchange 2010 server by manually adding details of the shared mailbox to the Outlook profile.

Outlook 2010 and 2007 clients run Autodiscover in a background thread each time they start and every 60 minutes thereafter, to ensure that clients always connect to the right resources. To pick up the new shared mailbox, you can either exit and restart Outlook, or you can wait until Autodiscover runs again, which should take no longer than 60 minutes. In either case, Outlook receives the information about the new shared mailbox from Autodiscover, automatically opens the shared mailbox, and lists it in the resources that are available to you. Figure 2 shows the list of resources that are available to me when I start Outlook. You can see that the Billing mailbox is listed, along with its archive.

Figure 2: Shared mailboxes listed by Outlook
OWA doesn't use Autodiscover, so you need to open a shared mailbox each time you want to access its contents. To open a shared mailbox in OWA, click the name of your mailbox in the upper-right corner to reveal a set of options, then select Open Other Mailbox. Input the name of the mailbox that you want to open, press Ctrl+K to have Exchange validate the name, and then click Open. OWA opens the shared mailbox instead of your regular mailbox.

Sending Mail from a Shared Mailbox

The FullAccess right gives you the ability to open a shared mailbox and manipulate its contents, including the ability to create and save a message. However, you must also possess the SendAs right before you can send a message. Therefore, you need to run both the Add-MailboxPermission and Add-RecipientPermission cmdlets.

To use Outlook to send email on behalf of a shared mailbox, create the message as you normally would, and then select the name of the mailbox that you want to send from. To do so, simply click the From field in the message header. Outlook 2010 always displays this field when more than one mailbox is configured in a profile, but you'll need to select the Show From field option to reveal the field in Outlook 2007.

By default, your regular email address is shown in the From field. Click the button to select from the mailboxes that you have used before, or click Other Email Address and then select any mailbox from the Global Address List (GAL). Outlook puts the email address of the selected mailbox into the message header. You can validate the address by reviewing the message properties, as Figure 3 shows.

Figure 3: Name of the shared mailbox in the message header

Who Sent Mail?

Both Exchange 2010 and Office 365 allow you to audit messages that delegates, using the SendAs right, send from shared mailboxes. To do so, use the mailbox auditing feature that was introduced in Exchange 2010 SP1.This useful feature helps to protect the integrity of sensitive mailboxes, such as those that are used by senior executives or that contain confidential information, such as discovery search mailboxes. The feature can also help to answer the question of who sent a message from a shared mailbox.

Mailbox auditing is disabled by default; you don't necessarily want audit entries to accumulate without good reason. Therefore, the first step is to enable auditing for selected shared mailboxes. No ECP UI is available for this task, so run the Set-Mailbox command

Set-Mailbox -Identity "Billing" -AuditEnabled $True

Users or delegates are unaware when mailbox auditing is enabled. Auditing is performed for whichever actions you select. The SendAs action, which is the one we're interested in for this example, is among the default set of actions that are always audited unless an administrator opts to exclude them. Each action is stored as an audit item and is held for 90 days -- a limit that you can configure by setting the AuditLogAgeLimit property -- in the Recoverable Items\Audit subfolder in the mailbox for which auditing is enabled. Regular clients such as Outlook and OWA can't access this location, although it can be accessed by using utilities such as MFCMAPI

Regretfully, Exchange doesn't provide any nicely packaged utilities to search audit log entries. Therefore, we must use the Search-MailboxAuditLog cmdlet. Here's a simple example that scans the Billing shared mailbox for any audit entries that indicate delegate-sent messages: 

Search-MailboxAuditLog -Identity "Billing" -ShowDetails |
Where {$_.Operation -eq "SendAs"} | Format-Table Operation,
OperationResult, LogonUserDisplayName, ItemSubject,
LastAccessed -Auto

You can see the result of this code (which should be entered as one line) in Figure 4. This figure clearly shows that I'm the culprit who sent the offending message from the Billing mailbox.

Figure 4: Scanning a mailbox audit log for SendAs entries

Where Things Go

Copies of messages that a delegate sends are stored in the Sent Items folder of the delegate's default mailbox. Even though this arrangement caused much grumbling from users, it's how Exchange and Outlook have worked for years. Eventually, Microsoft got the message and introduced a registry option in Outlook 2010 SP1 and Outlook 2007 SP2. If you want Outlook to store sent messages in the Sent Items folder of the shared mailbox, then update the registry by adding the new DWORD value HKCU\Software\Microsoft\Office\[version]\Outlook\Preferences\DelegateSentItemsStyle, where [version] is 12.0 for Outlook 2007 or 14.0 for Outlook 2010. If the value is missing or is set to 0 (zero), then Outlook behaves as before. Set the value to 1 (one) to make Outlook change the location in which it keeps sent items.

A similar issue exists with items that a delegate deletes from a shared mailbox. Logically, you might think that these items would go into the Deleted Items folder of the shared mailbox. But by default, Outlook moves such items into the Deleted Items folder of the delegate's mailbox. Fortunately, another registry fix is available to force Outlook to move deleted items into the Deleted Items folder of the shared mailbox instead. Insert the new DWORD value, at HKEY_CURRENT_USER\Software\Microsoft\Office\[version]\Outlook\Options\General\DelegateWastebasketStyle , and set the value to 4 (four). It would be nice if Microsoft had used keys in the same registry location to control both preferences for delegate behavior, but I suppose the fixes might have been made by two different teams. (And as always, modify the registry at your own risk!)

Other Types of Non-Standard Mailboxes

In addition to regular and shared mailboxes, Exchange 2010 supports special-purpose mailboxes that are used to book rooms and equipment. In effect, these are different kinds of shared mailboxes. ECP for Office 365 doesn't allow you to create these types of mailboxes either, but again, it's easy to do with EMS.

Room and equipment mailboxes are scheduled by including them as a resource in a meeting request. You never log on to these mailboxes or their associated accounts; the only folder that's used in these mailboxes is the Calendar folder.

You don't need to pay for an Office 365 subscription to create and use room and equipment mailboxes. To create a new room mailbox, run the New-Mailbox cmdlet and pass the -Room parameter, such as I've done in this example:

New-Mailbox -Name "Office" -Room

An equipment mailbox is created in a similar manner, using the -Equipment parameter instead:

New-Mailbox -Name "Projector" -Equipment

Although simply creating the mailboxes is enough to use them for scheduling purposes, I also run the Set-CalendarProcessing cmdlet to tell Exchange to accept meetings automatically. And I run the Set-MailboxCalendarConfiguration cmdlet to tell Exchange in which time zone the room or equipment is located: 

Set-CalendarProcessing -Identity "Office"
-AutomateProcessing AutoAccept

Set-MailboxCalendarConfiguration -Identity "Office"
-WorkingHoursTimeZone "GMT Standard Time"

Behind the scenes, Exchange runs background assistant processes to perform various tasks. Setting AutoAccept on a room or equipment mailbox means that the Calendar Attendant will update calendars as users generate requests; the Resource Booking Assistant will accept bookings based on the policy that you apply. For example, you can set the properties of a room mailbox so that only specific users are allowed to book it. All these approaches work equally well with on-premises Exchange 2010 servers.

Room Lists

Exchange 2010 SP1 introduced the concept of a room list, to help users navigate through the masses of rooms that are often found in large companies. Again, although ECP in Office 365 doesn't officially support room lists, there's nothing to stop you creating lists for use with Outlook 2010, which is the only client to support this feature.

A room list is simply a special form of DG whose membership is composed of room mailboxes. Exchange doesn't allow you to add other kinds of mailboxes to a room list. To create a room list, run the New-DistributionGroup cmdlet and pass the -RoomList parameter, as this example shows: 

New-DistributionGroup -Name "House Rooms"
-ManagedBy "Tony Redmond" -RoomList

This action creates an empty container that you can then populate with room mailboxes. Specifying the person who manages the DG is useful if you want to assign the task to someone other than an administrator.

Next, add the room mailboxes to the room list by using the Add-DistributionGroupMember cmdlet:

Add-DistributionGroupMember -Identity "House Rooms"
-Member "Office"

In effect, this action creates a pointer between each room and the room list so that when a user accesses the room list, Exchange knows which rooms to display. You can see a list of the rooms in a list by using the Get-DistributionGroupMember cmdlet

Get-DistributionGroupMember -Identity "House Rooms"

After you've populated your room list, you can use it with Outlook. Figure 5 shows the general scheme in action. A drop-down box called Show a room list, on the right side of the Schedule Appointment form, shows any room lists that are defined in the GAL, as well as any room mailboxes that you've used to book a room with Outlook. If you click the drop-down list and select a room list, Outlook populates the list of available rooms with whichever rooms in that list are available at the proposed time for the meeting. You can then select a room and add it to the meeting.

Figure 5: Using a room list with Outlook 2010

Rooms can be booked as meeting resources with OWA, but OWA doesn't support room lists. Instead, you must select individual rooms and add them to the meeting request. Again, all this works nicely with on-premises Exchange 2010 as well as Office 365.

Exchange Online Is Exchange!

The thing to remember about Exchange Online in Office 365 is that it's really just Exchange 2010 adapted for Microsoft's hosting environment. Most features that work for on-premises Exchange 2010 work equally well for Exchange Online, even if Microsoft hasn't yet fully exposed them in the ECP GUI. Over time, I've no doubt that Microsoft will increase the number of features that the ECP supports, but that's no reason to lose out on those features now. So don't wait: Start using all the various kinds of non-regular mailboxes today.