Processing meeting requests according to policy
The AutomateProcessing property of a room mailbox tells the
Resource Booking Attendant how to handle incoming meeting requests
within the structure established by the booking policy for the mailbox.
Three values can be present:
None. Exchange does not process incoming meeting requests.
AutoUpdate. This
used to be the default setting for all mailboxes (including room
mailboxes), and it allows the Calendar Assistant to place tentative
meeting requests in user calendars without any intervention from the
user. The user has to open and respond to the meeting request before it
is confirmed or rejected.
AutoAccept. This
is the default value set for room mailboxes created with Exchange 2013.
It enables the Resource Booking Attendant to process incoming requests
and accept or reject them according to policy.
To check which values are set for your room mailboxes, use this command:
Get-Mailbox –Filter {ResourceType –eq 'Room'} | Get-CalendarProcessing | Format-Table Identity, AutomateProcessingRequests
to include room mailboxes in meetings are either in policy or out of
policy. In-policy means that the request complies with the policy
because it’s inside the time permitted to book the room, is a suitable
length, doesn’t clash with other requests, and so on. Table 1 lists the properties that influence how the Resource Booking Attendant applies policy to incoming meeting requests for a room.
Table 1. Properties that influence processing of room bookings
Property | Meaning |
|---|
AllBookInPolicy | If $True, the assistant automatically approves in-policy requests to book the room from all users. |
AllRequestInPolicy | If
$True, the assistant tentatively accepts in-policy requests to book the
room from all users. Requests must be approved by a room delegate
unless the AllBookInPolicy property is $True. |
AllRequestOutofPolicy | Governs whether out-of-policy requests are acceptable for the room. All such requests have to be approved by a room delegate. |
BookInPolicy | Lists the users whose requests to book the room are automatically accepted. |
RequestInPolicy | Lists
the users who are allowed to submit in-policy requests to book the
room. All requests have to be approved by a room delegate. |
RequestOutofPolicy | Lists
the users who are allowed to submit out-of-policy requests to book the
room. All requests have to be approved by a room delegate. |
ProcessExternalMeetingMessages | Determines whether meeting requests will be accepted from users outside the Exchange organization. |
As noted earlier, Exchange 2013 attempts to simplify calendar
processing by reducing the number of options available through EAC. In
previous versions, you could specify the names of users who are allowed
to submit in-policy requests that the Resource Booking Attendant would
immediately accept. You could also specify a separate list of other
users who would be forced to have their meeting requests approved by a
room delegate before acceptance. You can specify room delegates through
EAC (Figure 4),
but because EAC does not expose the properties for the more advanced
policy settings through its UI, they must be updated through EMS if you
want to exert the maximum control over how incoming meeting requests
are processed for a room mailbox.
The default situation is as follows:
AllBookInPolicy is set to $True, and AllRequestInPolicy is set to $False. This
combination means that the Resource Booking Attendant can automatically
approve any in-policy request to book the room from all users. An
in-policy request doesn’t exceed the maximum meeting time, is booked
within the maximum request period, and so on.
BookInPolicy is blank. No
special setting is in place to list users whose requests to book the
room will be automatically accepted by the Resource Booking Attendant
(if in policy). This is what you’d expect because AllBookInPolicy is
set to $True.
RequestInPolicy is blank, too, for much the same reason. It
wouldn’t make sense to create a list of users who are forced to submit
meeting requests for approval if the Resource Booking Attendant
automatically accepts every in-policy meeting request.
AllRequestOutofPolicy is $False. Users are not allowed to request out-of-policy slots in the room’s calendar.
RequestOutofPolicy is blank. Because no out-of-policy meetings will be accepted, you don’t need to tell Exchange which users can set up such meetings.
ProcessExternalMeetingMessages is $False. You
do not want to receive meeting requests from outside the organization.
If set to $True, the Resource Booking Attendant applies the same policy
conditions that exist for internal requests.
Now
assume that you want to create special processing for a meeting room
that needs to be tightly controlled, such as the meeting room adjacent
to the CEO’s office that is typically used for meetings that involve
the CEO. You therefore want to keep this meeting room as available as
possible for the CEO and her staff.
The first thing to do is
amend the properties of the CEO Meeting Room so that it has at least
one delegate. If you don’t do this, the Resource Booking Attendant
cannot forward meeting requests for approval, and the meeting will
remain in a perpetual state of tentativeness. If you specify one or
more delegates and set Select Delegates Who Can Accept Or Decline
Booking Requests, EAC sets the AllBookInPolicy property to $False and
the AllRequestInPolicy to $True when you save the changes. As soon as
the change is made, Exchange routes any meeting request booked for the
room to the delegates for approval.
The request is noted as
tentative in the room’s calendar until a delegate decides to accept or
reject the request by responding to the message requesting a decision
that the Resource Booking Attendant sends to him. Only one of the
delegates has to give her approval for the meeting to be accepted (Figure 5).
Note that a delegate cannot approve her own request for a room. To
avoid this situation, you should add room delegates to the list of
users whose request to book a room is automatically approved.
The
CEO and his executive staff will probably not be impressed if a meeting
they set up in the room needs to be approved. The best solution is to
add the members of the executive staff to the BookInPolicy property so
that any meeting requests they create are automatically accepted. You
can identify users or groups by name, alias, UPN, or SMTP address. It’s
easiest if you use a distribution group to assign the exception because
it’s much easier to type the name of the group than all the individual
users. A command like this should do it:
Set-CalendarProcessing –Identity 'CEO Meeting Room' –BookInPolicy 'Executive Staff'
If you do want to add individual users to the exception list, put a comma between each name.
Equipment
mailboxes are very similar to room mailboxes in the properties you can
assign to set a policy for their booking and the way the Resource
Booking Attendant can monitor and process incoming meeting requests.
Use this command to find the equipment mailboxes within your
organization:
Get-Mailbox –Filter {ResourceType –eq 'Equipment'}From
a user perspective, equipment mailboxes are added to meetings like any
other recipient. Unlike room mailboxes, neither Outlook Web App nor
Outlook provides a specific list to enable users to select equipment to
include in meetings, nor is there an All Equipment address list through
which to browse to find equipment. For this reason, it’s important for
the naming convention applied to equipment mailboxes to identify these
mailboxes clearly in the GAL.
