Exchange 2013 supports mailboxes that are configured to represent
rooms that can be added to meeting requests. Equipment mailboxes are a
further mailbox variation that can be attached to rooms to represent
the various items that support holding meetings in the room such as
whiteboards, projectors, and tables. Although all mailboxes occupy
space in databases, room and equipment mailboxes are differentiated
through the type assigned to the mailboxes and the properties you can
set on the mailboxes. Collectively, room and equipment mailboxes are
referred to as resource mailboxes.Note
Resource
mailboxes have disabled Windows accounts. To create a separation
between normal user accounts and resource mailboxes, it’s a good idea
to place these accounts in a separate Active Directory OU. No one ever
needs to log on to a room or equipment mailbox to process the meeting
requests they receive. As you’ll see, the Resource Booking Attendant
handles these requests automatically to confirm the booking or deny it
because someone else has already booked the room.
Despite
the fact that Exchange provides a useful All Rooms address list you can
use to filter out room mailboxes when you browse the GAL (Figure 1),
it’s still important to use a suitable naming convention to identify
room mailboxes to users and to populate information such as capacity
and location to help people find the right room. Some companies name
their rooms after cities, others after important or well-known people,
and others after scientific inventions. Whatever convention you adopt,
make sure that it is used consistently.
Outlook
and Outlook Web App clients can include room mailboxes in calendar
requests and can use a special form of distribution group called room
lists to select from subsets of room mailboxes when scheduling
meetings. This is a useful feature in large organizations when hundreds
of room mailboxes might be in the GAL.
You can discover the current set of room mailboxes with this command:
Get-Mailbox –Filter {ResourceType –eq 'Room'} | Format-Table Name, Res* -AutoSizeDefining custom properties for resource mailboxes
You see two properties listed that can be used to communicate
details about the rooms to users when they decide which room they’d
like to book. The ResourceCapacity property states the number of people
that can fit in the room. This is purely advisory; Exchange doesn’t
apply any intelligence to meeting requests to check that the number of
attendees listed doesn’t exceed the capacity of the selected room. The
ResourceCustom property enables administrators to indicate whether
anything special is available in the room. Before you can populate any
value in the ResourceCustom property, you have to create a set of
custom properties for the resource configuration with the
Set-ResourceConfig cmdlet. For example, this command creates a basic
set of items you might find in a room:
Set-ResourceConfig –ResourcePropertySchema ("Room/TV", "Room/Concall", "Room/WiFi", "Room/Whiteboard", "Room/Video", "Room/ComfortableChairs")The
resource values can’t have spaces and can’t include hyphens (as in
Wi-Fi). There is no UI in EAC to manage or expose the set of custom
properties. If you need to update the set of custom properties, you can
either rewrite the complete set or update the current set with a couple
of lines of EMS code. For example:
$CurrentConfig = Get-ResourceConfig
$CurrentConfig.ResourcePropertySchema+="Room/PictureWindow"
Set-ResourceConfig –ResourcePropertySchema $CurrentConfig.ResourcePropertySchema
Note
that the set of custom properties can also contain properties that
differentiate equipment mailboxes. All the entries in the set you have
seen so far are prefixed with “Room/” so Exchange knows that these
properties apply to room mailboxes only. Properties used with equipment
mailboxes are prefixed with “Equipment/” and can be added in exactly
the way described earlier. After the resource configuration is
populated, if a room was equipped with a Wi-Fi access point, that could
be indicated by setting the property as follows:
Set-Mailbox –Identity 'Liverpool Conference Room' –ResourceCustom ('WiFi')This
command overwrites any existing custom properties that exist for the
mailbox. If multiple custom resources are available in a room, you can
populate them like this:
Set-Mailbox –Identity 'Liverpool Conference Room' –ResourceCustom ('WiFi', 'Concall')The
Exchange 2010 EMC reveals these properties through its GUI. However,
EAC does not, so you have to manipulate resources custom properties
through EMS.
Providing policy direction to the Resource Booking Attendant
Another important property is shown on the Resource General
tab. When you enable the Resource Booking Attendant, you instruct
Exchange that the attendant should monitor incoming meeting requests
for the room to decide whether the requests should be accepted. The
policy set for the room mailbox determines the action the Resource
Booking Attendant takes. Each room mailbox can have a distinct booking
policy you can see through the booking options section of a room
mailbox’s properties (Figure 2).
If you compare the information and options presented by EAC to the
equivalent shown by the Exchange 2010 EMC (on the Resource Information
and Resource Policy tabs of a room mailbox’s properties), you can
quickly see that Exchange 2013 has considerably simplified the set of
options available to administrators. However, this is only true for
EAC; all the properties that can be tweaked to make the Resource
Booking Attendant deal with a room precisely as you wish are still
available through EMS.
Unlike
in Exchange 2010, EAC does not display the properties that control how
the attendant publishes information extracted from incoming requests
that it adds to the calendar of the room mailbox. This information is
exposed if a user browses the room’s calendar to look for a suitable
time to schedule a meeting. The default is to remove any attachments,
comments, and subjects for meetings because they often contain
confidential information that you don’t want all to see if they look
for a meeting slot. You can change what items the Resource Booking
Attendant publishes with the Set-CalendarProcessing cmdlet. The most
important property you can manipulate is the value set for
AutomateProcessing, which tells the Resource Booking Attendant how it
should interact with the room mailbox. For now, assume that this
property is set to AutoAccept, meaning that the Resource Booking
Attendant can automatically process incoming calendar requests to
reserve a time slot in the room’s calendar. When this is established, a
number of other properties influence what the Resource Booking
Attendant does with a calendar request, including:
DeleteAttachments. Delete
any attachments that are included with a calendar meeting request.
Attachments are of interest to the humans that receive the request but
are not needed by a room mailbox.
DeleteComments. Delete any comments sent along with a calendar meeting request.
DeleteSubject. Delete the subject of the meeting.
DeleteNonCalendarItems. Because
a room mailbox is a mailbox with an SMTP address, users can send it
email. It’s pointless, but it can be done. The best thing is to
suppress any noncalendar items that arrive in a room mailbox, so
Exchange does this by default. Apart from anything else, this stops the
mailbox from filling up with useless material that will never be read
by anyone.
AddOrganizerToSubject. When
people browse a room mailbox’s calendar, they might want to know who
has a room booked at a particular time. By default, Exchange adds the
name of a meeting organizer so that this information is available to
others. Sometimes this is extremely useful, like when knowing whom you
might be able to persuade (or force) to give up a valuable time slot.
However, it might be construed that letting others know who has booked
a room gives away just too much information, in which case, you can
update this property to $False.
RemovePrivateProperty. Meetings
that are flagged as private have the private flag removed if a room
mailbox is included. If you want to keep meetings really private, you
probably shouldn’t book a room—or arrange for this property to be set
to $False.
OrganizerInfo. If
set to $True, the Resource Booking Attendant sends meeting organizers
an information message if a meeting request is declined because of a
conflict. It’s then up to the humans to resolve the conflict.
AddNewRequestsTentatively. Incoming meetings that are auto-accepted should be marked as tentative on the room mailbox’s calendar.
The
complete set of calendar properties that influence the processing of
calendar requests can be accessed with the Get-CalendarProcessing
cmdlet. Note that these properties are present for all mailboxes and
not just for room mailboxes. For now, examine the calendar processing
properties for a room with:
Get-CalendarProcessing –Identity 'Leixlip Conference Room' | Format-Table
The
Calendar Assistant can be configured to remove old meeting requests and
responses from a room mailbox, but you can also apply a retention
policy to room mailboxes to have old items cleaned up from their
calendar after a suitable period (maybe two years).
At the bottom
of the booking options section, you can see a field to allow
administrators to provide some additional text the attendant inserts
into messages that confirm or deny meeting requests. Administrators
often use this property to describe the room or provide some
information about how people can find the room if it’s located in one
of the cube-filled labyrinths favored by large corporations. You can
see how this text appears to users in the bottom of the rejection
message illustrated in Figure 3.
Booking options (Figure 2)
for a room mailbox define basic rules for the Resource Booking
Attendant to follow when it examines incoming meeting requests. Basic
conditions include items such as whether the room is available outside
normal working hours, how long meetings can last (the default is 1,440
minutes, or 24 hours; this allows for all-day meetings, but you might
want to shorten the value), and whether to accept requests to schedule
repeated meetings such as a team meeting that occurs at the same time
every week. It’s also possible to prevent people from booking rooms too
far in the future (180 days is the default) and to apply some level of
automation to the resolution of conflicting requests. For example, the
ConflictPercentageAllowed property (only available through EMS) sets a
threshold for the instances of a recurring meeting that create
conflicts, so if this property is set to 20, then any request for a
recurring meeting will be declined if more than 20 percent of the
meeting instances cause a conflict.
To
allow access to the calendar of a room mailbox, you use the
Add-MailboxPermission cmdlet to assign the ChangePermission right to
the user to whom you want to grant access to the calendar.
Add-MailboxPermission –AccessRights FullAccess –User 'Smith, Samantha'
–Identity 'Galway Conference Room'
When
the permission to access the calendar is assigned, the assignee can
open the calendar just like any other shared calendar and browse the
entries to resolve conflicts. It’s often easier and better for all
concerned when a human resolves conflicts because he has much better
knowledge of the organization context than any computer-driven process.
In this instance, you can see that the CEO has requested use of a room,
and that this conflicts with two other requests. Because Exchange does
not assign a weighting to calendar requests that come from different
types of users, a computer deals with the CEO’s request as it deals
with any other request. In most cases, a human will quickly realize
that the right course of action is to let the CEO have the room and
tell the other requesters that they’ll have to find a different room—or
argue with the CEO.
Calendar-related mailbox properties can be
updated with the Set-CalendarProcessing cmdlet. For example, to
restrict booking slots to 45 minutes and to accept booking requests
only up to 120 days in advance:
Set-CalendarProcessing –Identity 'Leixlip Conference Room'
–MaximumDurationInMinutes 45 –BookingWindowInDays 120
Note
The
Get-CalendarProcessing and Set-CalendarProcessing cmdlets replace the
Get-MailboxCalendarSettings and Set-MailboxCalendarSetting cmdlets used
in Exchange 2007, so you will have to update code if you have any
scripts that use these cmdlets.
You can set the available
hours for a room mailbox with the Set-MailboxCalendarConfiguration
cmdlet. First, find out what the current settings are with the
Get-MailboxCalendarConfiguration cmdlet. An edited version of its
output is shown here:
Get-MailboxCalendarConfiguration –Identity 'Leixlip Conference Room' | Format-List
WorkDays : Weekdays
WorkingHoursStartTime : 08:00:00
WorkingHoursEndTime : 17:00:00
WorkingHoursTimeZone : Pacific Standard Time
WeekStartDay : Sunday
Because
the booking of meeting rooms is a time-sensitive activity, it’s
important to set the mailbox’s time zone correctly so that it
corresponds to the location of the meeting room. The default time zone
is inherited from the server on which the mailbox is created. In this
case, you know that Pacific Standard Time (PST) is inappropriate
because the room is located in Dublin, so update the time zone property
as follows:
Set-MailboxCalendarConfiguration –Identity Leixlip 'Conference Room'
–WorkingHoursTimeZone 'GMT Standard Time'
