How to Install, Configure, and Manage the Mailbox Role in Microsoft Exchange Server 2013

Objective 1.6: Create and configure mail-enabled objects

Recipients and mail-enabled objects are the core of the Exchange environment. A mail-enabled object is an object, such as a user mailbox, to which Microsoft Exchange can deliver or route messages. Exchange 2013 supports multiple different types of mail-enabled objects enabling various collaboration scenarios.

Configuring resource mailboxes and scheduling

Resource mailboxes are mailboxes that represent a location based, or a nonlocation-based, resource, such as a meeting room or a projection system. For these shared resources, resource mailboxes provide the ability to send requests that allow the requestor to reserve the resource. The scheduling can be automated, if desired, in which case, the Exchange assistant processes automatically accept or decline the requests based on the defined time and availability restrictions. You also have an option to configure such resources to be managed by a delegate. In such cases, the delegate is responsible for manually accepting and rejecting the resource scheduling requests based on business processes or other approval criteria.

Location based resources are addressed in Exchange 2013 as room resources. When you create a meeting request, Outlook client automatically shows you the Room Finder with all of the available rooms. You can then select an appropriate room for your meeting and reserve it if it’s available for the scheduled meeting time. Recurring requests can also be sent to the room resources and, if automatic processing is configured, acceptance depends on the configured criteria.

To create a room resource, you can use the New-Mailbox cmdlet with the Room parameter. You can also create a room resource from EAC. Let’s create a room resource for a room called New York Executive Briefing Room using EAC.

To create a room mailbox, select the Resources tab from the recipients section, and then click + and, from the resulting drop-down menu, select the Room Mailbox option, as you can see in Figure 1–7.

The resulting dialog box in Figure 1–8 enables you to provide the required details, such as display name, alias, room capacity, and location.

You can also provide an organization unit (OU) if you need to store the resource mailbox you’re creating in a specific OU. Creating the same resource mailbox using the Shell would look like the following.

Creating a room resource mailbox using the Shell

New-Mailbox `
-Name 'New York Executive Briefing Room' `
-DisplayName 'New York Executive Briefing Room' `
-ResourceCapacity '10' `
-Alias 'NYEBR' -Office 'New York City Office' `
-Room:$true

When creating the resource mailbox using EAC, you might notice it applies additional defaults to the room mailbox, such as the automatic acceptance of meeting requests.

Once created, room resources can be configured to set the meeting length and recurrence limits, assign a delegate, and auto reply to senders. Let’s configure the room resource just created to limit the meeting duration to two hours and a recurrence limit of no more than three months from the request date. Using Shell, you need to use the Set-Mailbox cmdlet as follows.

Configuring room resource parameters

Get-Mailbox NYEBR | Set-CalendarProcessing -MaximumDurationInMinutes 120
-BookingWindowInDays 90

When using Outlook to create a meeting request, the newly created room is now visible in Room Finder. In large organizations with many locations and rooms, organizing rooms by location becomes critical to enable users to efficiently locate room resources without sifting through a long list of room resources. Exchange 2013 allows creating room lists, which enables you to organize room resources by location.

Essentially, room lists are distribution groups with RoomList designation. Once you create a room list, you can add rooms that belong to the location the room list represents. Let’s create a room list for the New York City location and add the room resource created earlier to the room list.

Creating room list and adding room resource to the room list

New-DistributionGroup -Name "New York City Conference Rooms" –RoomList
Add-DistributionGroupMember -Identity "New York City Conference Rooms" -Member NYEBR

Figure 1-9 shows an example of a new meeting dialog box, which shows both the room list and the room created earlier in the Room Finder.

As mentioned, Exchange 2013 also enables you to create nonlocation-specific resource mailboxes, such as shared equipment. While most of the cmdlets and parameters are the same, the difference is, when creating an equipment resource, you issue the New-Mailbox cmdlet with –Equipment:$true, instead of –Room:$true used in the earlier example. Also note, you can’t create special equipment distribution lists as you can with room lists.

Configuring team mailboxes

A shared mailbox is a resource created when multiple users need to access common information. This could be a mailbox receiving support queries from customers or a shared calendar for a team working on a project. This shared resource isn’t a user mailbox and it doesn’t have its own username and password. Instead, users logon to their own mailboxes, and then connect to the shared mailbox to access shared information.

You can create a shared mailbox using the New-Mailbox cmdlet with the Shared parameter. Once created, you can assign specific permissions to the team members or a distribution group to access the mailbox, and to be able to send as, or on behalf of, the shared mailbox. The three permissions need to be assigned using three unique methods. To assign full permissions to the mailbox so a user can manage the mailbox content, including editing and deleting mailbox items, you need to use the Add-MailboxPermission cmdlet with the FullAccess parameter.

To assign the send on behalf of permission, you need to use the Set-Mailbox cmdlet with the GrantSendOnBehalfTo permission. To assign the send as permission, you need to use the Add-ADPermission cmdlet.

When a user is assigned full permission on the shared mailbox, the Exchange auto-mapping process includes the mailbox in an Autodiscover response. If the user’s Outlook client is configured using Autodiscover, the shared mailbox is automatically connected to the user’s profile and becomes visible in the navigation pane, as you can see in Figure 1–10.

While auto-mapping can help a user eliminate manual steps required to connect to a shared mailbox, if a user has permissions on multiple shared mailboxes, connecting all of them to the Outlook client automatically might become unnecessary.

Exchange 2013 provides an administrator with the ability to turn off auto-mapping for a given mailbox. The administrator can simply disable auto-mapping by setting the Automapping parameter value to $false when assigning permissions to the user using the Add-MailboxPermission cmdlet. If you want to disable auto-mapping after assigning the permissions, you must first remove the permissions, then assign them again with the Automapping parameter set to $false.

Configuring distribution lists

Distribution lists provide an important collaboration capability by allowing a sender to reach a group of recipients by sending an email to a group object, instead of sending it to each recipient individually.

When you create a new distribution group, Exchange creates a universal distribution group object in Active Directory. To mail enable an existing group in Active Directory, it must be a universal distribution group. But if you migrated from a previous version of Exchange server, it’s possible you have distribution groups that are security groups, domain local groups, and global distribution groups in Active Directory.

By default, Exchange 2013 enables not only administrators, but also users to create distribution groups. When a user creates a distribution group, the user is the designated owner of the distribution group, and they can manage membership and other attributes of the group. When an administrator creates a distribution group, they can designate an appropriate individual as the owner of the group, which in turn, enables the designated owner to manage the distribution group membership and related configuration.

If you want to block the end users’ ability to create their own distribution groups, you can use RBAC assignment policies to change the default permissions assigned to the users and block their ability to create a distribution group. You can also allow users to manage group members for the groups for which they’re the designated owners, while removing their ability to create new distribution groups.

To provide the consistent naming of distribution groups in the organization, you can create a distribution groupnaming policy, which enables you to configure a prefix and a suffix based on predefined text or by using the value of an attribute, such as city or title. The group naming policy is stored at the organization level and can be created or changed using the Set-OrganizationConfig cmdlet with the DistributionGroupNamingPolicy parameter. You can only have a single group naming policy for an entire organization. When creating distribution groups using EAC, group naming policy is automatically ignored. If administrators use Shell to create a distribution group, the group naming policy is applied to the name unless the administrator uses the IgnoreNamingPolicy parameter.

Because distribution groups contain multiple users from a specific department or an entire organization, depending on the purpose of the distribution group, it’s important to manage whether distribution groups accept email from outside senders or only from senders within the organization. By default, newly created distribution groups only accept emails sent by senders from the same organization. An administrator can configure a distribution group to accept messages from outside senders, if desired.

Along with simple email sender restrictions, distribution groups also allow for moderation capabilities. When enabled, a moderator or a group of moderators, must be assigned, so when a message is sent to the distribution group, it can be approved or rejected. It is also possible to create exceptions, so certain senders don’t require approval by moderators to send messages to the distribution group.

Configuring moderation

As described in an earlier section, you can set moderation on distribution lists. But moderation is a transport function and it can also be applied to individual user mailboxes, if needed. To apply moderation to a distribution group, updating moderation properties of the distribution group is a relatively simple task. But, if you want to apply moderation to a user mailbox, you must create a transport rule that uses the Forward the message for approval action when an email is sent to a designated mailbox. In both cases, you can create exceptions, so designated senders can bypass the moderation process. The moderators always bypass the moderation process when they send an email to the distribution group or the mailbox they’re required to moderate.

When a mailbox or distribution group configured for moderation receives a message, the message is forwarded to the moderators. Moderators can approve the message, in which case, the message is delivered to the intended recipients. The moderators can reject the message and, optionally, choose to provide a reason for the rejection, which is then visible to the sender without revealing the identity of the moderator; or the moderator can ignore the message, which eventually times out and the sender is notified that no action was taken by the moderator.

Because moderation is a transport function, it’s important to understand that when co-existing with Exchange 2007, the moderation might not work when the message is routed through an Exchange 2007 hub transport server.

When a message is sent to multiple recipients and only a subset of the recipients are moderated, the messages is bifurcated. One message is sent to the recipients who don’t require moderation and that message is delivered immediately. The other message is sent to the moderator, who must take the appropriate action. The message is then sent to the recipient or back to the sender, based on the moderator’s action.

When a distribution group is moderated and it contains recipients who are also moderated, moderation must take place for each moderated recipient individually, even after the message is approved by the moderator of the distribution group. This might not be a desired behavior in certain environments. Distribution groups allow the moderator-accepted message to bypass further moderation when the BypassNestedModerationEnabled attribute is configured.

When more than one moderator is assigned to a distribution group or a recipient for moderation, what happens when one moderator approves the message while another rejects it? The moderation process ignores the subsequent moderator actions once it receives the first moderator’s response. Whatever action the first moderator decides to take remains valid and the message is processed accordingly. If one moderator approves the message and other moderators are away, the message is deleted from their mailboxes by the moderation process because the message no longer needs a moderator’s decision.

Configuring a linked mailbox

A linked mailbox is a mailbox accessed by a user who is in a separate trusted forest. Most common Exchange 2013 deployments are single forest deployments. But deployment requirements might exist where account forests that host user accounts are separated from resource forests that serve resources, such as Exchange mailboxes. In such a case, the two separate forests require a trust configured to allow the use of resources by the users from the separate forest. The trust must be set up, so the resource forest trusts the account forest.

While the one-way outgoing trust is sufficient to create linked mailboxes, the administrator is required to provider administrator credentials of the account forest every time a linked mailbox is created. This behavior can be avoided if a one-way outgoing trust is also established from the account forest trusting the resource forest, which is hosting the linked mailboxes.

Before you can create a linked mailbox, the user account, also known as master linked account, must exist in the account forest. To create a linked mailbox, use the New-Mailbox cmdlet. You need to provide a linked domain controller name and a linked master account name. The linked domain controller represents a domain controller in the account forest where the user account resides. The linked master account represents the user who is connected to linked mailbox. You also need to provide the administrator credentials of the account forest if the account forest doesn’t trust the resource forest.

The following example shows how to create a linked mailbox in the resource forest Contoso for Ayla Kol, whose user account resides in the Fabrikam forest.

New-Mailbox `
-Name "Ayla Kol" `
-LinkedDomainController "DC1_FABRIKAM" `
-LinkedMasterAccount "FABRIKAM\aylak" `
-OrganizationalUnit Users `
-UserPrincipalName aylak@contoso.com `
-LinkedCredential:(Get-Credential FABRIKAM\administrator)

If required, you can change the master account linked to the linked mailbox using the Set-Mailbox cmdlet with the LinkedMasterAccount parameter.

Objective summary

• Shared resources, such as Equipment and Room resources, can be managed in Exchange using special mailbox types. You can’t convert an existing user mailbox into a resource mailbox. You must create a new resource mailbox.
• Moderation is a transport function, and it can be applied to both distribution groups and individual users. It can also be applied to create multiple layers of moderation, if needed.
• Linked mailboxes requires the resource forest to trust the account forest. A trust from the account forest to the resource forest is optional.

Objective review

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

1. You configured a shared mailbox and assigned full permissions to users. One of the users mentioned they already have multiple mailboxes connected to their Outlook and they don’t want to connect to a shared mailbox automatically. What must you do?

   1. Run Set-ADPermission cmdlet.
   2. Run Set-Mailbox cmdlet.
   3. Remove mailbox permissions for the user, and then add it again.
   4. Run Set-CASMailbox cmdlet.

2. You deployed Exchange 2013 in a resource forest. You can configure required trust with the account forest. An administrator mentions they are prompted for the administrator account and password from the account domain every time they create a linked mailbox. What must you do to stop the credential prompts?

   1. Add an administrator’s account to the Domain Admins group in the resource forest.
   2. Add an administrator’s account to the Domain Admins group in the account forest.
   3. Add an administrator’s account to the Enterprise Admins group in the account forest.
   4. Create a one-way trust from the account forest to the resource forest.

3. You recently created a new distribution group with default settings. The distribution group must be able to receive emails from external senders. Which of the following meets the requirement?

   1. No further action is needed. Default settings of new distribution group allows external senders to send email to members of the distribution group.
   2. Configure AccessMessagesOnlyFrom parameter on the distribution group.
   3. Configure BypassModerationFromSendersOrMembers parameter on the distribution group.
   4. Configure RequireSenderAuthenticationEnabled parameter on the distribution group.