Exchange 2007 Resource Mailboxes
Believe it or not, this is the entry that prompted me to recreate my website back in 2009. My notes for this topic date back to March 2008. Best of all, this information pertains to Exchange 2007, and Exchange 2010 was released last year, so much of this information is probably obsolete.
Nonetheless, here goes: In Microsoft Exchange 2007, resource mailboxes are essentially mailboxes for inanimate objects. In theory, we use them for booking rooms, vans, projectors and laptops. The idea is that you use Outlook to book appointments, and you invite these inanimate objects to your meeting. Exchange then responds to your meeting requests on behalf of the inanimate objects. The inanimate object will approve your meeting request if (and only if):
- You have permissions to make booking requests
- It has the timeslot free
Resource mailboxes are supposed to look like regular users. In addition to accepting meeting requests, they have calendars that users can look through to find available meeting spots.
Simple, right? Wrong! Resource mailboxes are a mess. In particular, setting up resource mailboxes involves twiddling permissions on several different levels. They also don't work as you expect -- in particular, users want to interact with the Outlook calendars in completely intuitive ways that have disastrous results.
In this overview I will try to lead you through the maze of permissions, and I will point out some of the many quirks we have run into. If your organization is considering using resource mailboxes maybe you can show this article to your boss and find some other way to get things done.
My environment is: Exchange 2007 running on Windows 2003 R2 64-bit, and Office 2007 clients running on Windows XP.
Mailbox Setup
Configuring a resource mailbox involves the following steps:
- Setting up groups that will be able to interact with the mailboxes.
- Creating the mailbox in Exchange Management Console (EMC) or Powershell.
- Configuring the mailbox access options using Powershell.
- Configuring the "booking policy", which specifies who may interact with the resource mailbox and under what conditions. This involves Powershell.
- Setting the mailbox's working hours, which requires Outlook or Outlook Web Access under Internet Explorer.
- Setting calendar permissions, which requires Outlook.
There are a lot of permission levels to deal with here. Many of them appear to overlap, but in fact they don't.
Setting up Groups
I highly recommend using group permissions on your resource mailboxes, as opposed to giving individual Exchange users permissions on individual mailboxes. Otherwise you will have to go through this permissions nonsense for each user (or you will have to remember all of the steps when your usual booker quits his/her job in disgust and you have to set up the replacement worker).
Say you are using resource mailboxes for rooms and laptops. Then I would create three groups:
- "Booking Admins", which have access to everything and can administer the mailboxes.
- "Room Bookers", who can request room bookings.
- "Room Delegates", human beings who can grant room booking requests.
- "Laptop Bookers", who can request laptop bookings.
- "Laptop Delegates", human beings who can grant laptop booking requests.
You may need more granularity than this in your setup, but these three groups should be enough to get you started. Create them as mail-enabled security groups in Exchange Management Console. (I don't think making them distribution groups is enough.)
The "delegates" can be helpful if there is some administrative staffperson who needs to approve bookings -- either all bookings, or bookings from non-special people who are not permitted to book everything automatically.
Creating Mailboxes
If you are creating many mailboxes then it is more efficient to script a solution using Powershell loops. But for one or two mailboxes using the Exchange Management Console is fine. After creating a mailbox using the EMC, you get a Powershell snippet you can copy and modify for future mailbox creation.
I use the following name convention for mailboxes:
- Rooms begin with the word "Room". For example:
Room.Boardroom
,Room.Oubliette
. - Laptops begin with "Equipment.Laptop". For example:
Equipment.Laptop.lap02
. This allows me to create other categories (such as "Equipment.Projector" later.)
Creating the mailboxes in EMC is not hard:
- Create a new mailbox
- Designate it as a room or equipment mailbox
- Change the organizational unit. My LDAP tree has a folder called
Exchange Resources
, so I put resource mailboxes there. - Set the first name to have a period: "Room." or "Equipment.Laptop." I also modify the full name of the mailbox so that it does not contain any spaces.
- Set the storage group
You have to wait several hours before the mailboxes become active. (I am not sure exactly why -- maybe the entries have to propogate to the Global Address List?)
Once the mailboxes exist you can set mailbox access options in Powershell.
Configuring Mailbox Access
Resource mailboxes don't come with passwords (by default?) so you
can't use them to log into the domain. (This would probably be a bad
idea if it were allowed.) Therefore you need some other account that
will have full access to the mailboxes and can log in as those users.
I use the Booking Admins
group for this. Say my mailbox is
Room.Boardroom
. Then the following Powershell snippet should do the
trick:
Add-MailboxPermission -identity Room.Boardroom -user `
"mydomain\Booking Admins" -accessrights fullaccess `
-inheritancetype all
The above should be one line, or use the backticks as I have done to escape the linebreaks.
You don't have to use Powershell for this. In EMC, you can right-click
the mailbox in question, then choose Set Full Access Permissions
and
add the group.
Configuring Booking Policy
This is the interesting part. There are several properties to resource
mailboxes that you can set. There are a lot of options available. You
can see the options available for the mailbox Room.Boardroom
by
typing:
Get-MailboxCalendarSettings Room.Boardroom | fl | more
The meanings of the parameters are explained in a few different places:
- http://technet.microsoft.com/en-us/library/aa996340.aspx has a full list of properties and what they mean.
- http://msexchangeteam.com/archive/2007/05/14/438944.aspx has a good description of the process and policies you can specify.
- http://knicksmith.blogspot.com/2007/05/managing-resource-mailbox-calendars.html has another good explanation of the different policies and parameters you might consider.
I tend to focus on the following properties:
BookInPolicy
: Who can book (during office hours) without getting permission from a human being (aka a "resource delegate").RequestInPolicy
: Who can request bookings within the restricted times (e.g. working hours) and have them approved by a delegate. Note that this is more restrictive thanRequestOutOfPolicy
.RequestOutOfPolicy
: Who can make requests that can always be approved by a resource delegate, regardless of office hours.ForwardRequestsToDelegates
: Does this mailbox forward requests to human beings?ResourceDelegates
: Who is assigned to approve booking requestsScheduleOnlyDuringWorkHours
: If this is set, then many requests sent outside of working hours are auto-declined. You set working hours for the calendar using Outlook (ugh).AutomateProcessing
: Should the mailbox respond to requests automatically? I set this to "AutoAccept" always.EnforceSchedulingHorizon
: Should there be a limit on how far in the future you can book resources? I set this to$false
to allow recurring meetings.BookingWindowInDays
: How far in the future people can book the resource. I think this only matters ifEnforceSchedulingHorizon
is$true
Note that BookInPolicy
, RequestInPolicy
and RequestOutOfPolicy
take lists of accounts. There are three other properties:
AllBookInPolicy
, AllRequestInPolicy
and AllRequestOutOfPolicy
that take boolean values. Set (some of) them to $true
to treat all
users with the same policy.
For example, we have some offices that can be booked by anybody, for
any time. For these rooms we set AllBookInPolicy
to $true
.
Let's say the Boardroom should be bookable by "Booking Admins" always, and that "Room Bookers" may request the boardroom only during office hours. Requests are granted by "Room Delegates", and you can book meetings indefinitely into the future: The Powershell command for that might look like this (all as one line):
Set-MailboxCalendarSettings -identity mydomain\Room.Boardroom `
-AutomateProcessing: AutoAccept `
-ResourceDelegates: "mydomain\Room Delegates" `
-ForwardRequestsToDelegates: $true `
-EnforceSchedulingHorizon: $false `
-ScheduleOnlyDuringWorkHours: $true `
-BookInPolicy: "mydomain\Booking Admins" `
-AllBookInPolicy: $false `
-RequestOutOfPolicy: "mydomain\Room Bookers" `
-AllRequestOutOfPolicy: $false `
-AllRequestInPolicy: $false
Setting Working Hours
If you don't have ScheduleOnlyDuringWorkHours
set, then you don't
need to worry about this much. Otherwise, you have to define the
working hours for the Resource Mailbox.
You can do this in full Outlook 2007, but in order to do so you have
to make a new profile (in Control Panel -> Mail
) with the resource
mailbox name. I find it easier to use Outlook Web Access (OWA).
I don't know of a way to set this with Powershell, or by logging into
Outlook with anything other than the account belonging to the resource
mailbox.
Let's assume that we use the Room.Boardroom
example from before.
Log into Outlook Web Access using an account in the "Booking Admins" group (which was granted full access to the mailbox). You will need to use Internet Explorer, and run OWA in full mode.
In the OWA screen, click on your name (in the top right hand corner). You should now be able to enter another identity. Enter
Room.Boardroom
.Like magic, another window should pop open, revealing Room.Boardroom's mailbox. You can now go to
Options -> Calendar Options -> Calendar Work Week
in this mailbox and set the working hours.
Setting Calendar Permissions
In addition to mailboxes, resource mailboxes have associated calendars. Calendar support for resource mailboxes is broken. In particular, booking requests sent via e-mail (aka the "Resource Booking Assistant") will show up in the calendars of your resource mailboxes, but many intuitive operations on appointments that are already in calendars don't work right.
This is a pity, because we have found that our users want to interact with resource mailboxes by scheduling appointments and bookings directly in their calendars. This is fraught with danger. For this reason it might be better to keep the calendars for resource mailboxes totally hidden from users, and uncompassionately force your users to interact with the mailboxes only via the appointment interface in their own calendars. This is a terrible solution, however, because users want to see what calendar bookings are available at a glance.
With those disclaimers, here is how to allow others to see (and manipulate!) the calendars for resource mailboxes. This requires configuring yet another set of permissions, which can be accessed via Outlook (but not Outlook Web Access 2007, sigh).
We will again use the Room.Boardroom
mailbox as an example.
Start Outlook as a member of
Booking Admins
, which have full access to the resource mailbox.Click on
Calendars
and then goFile -> Open -> Other User's Folder
. ClickName
to browse the user list, and find the calendar. The folder type should becalendar
. This should open up the resource mailbox's calendar under "Other People's Calendars" [CHECK]In the calendar list, right-click the calendar and choose
Properties
, then choose thePermissions
tab. As a user with full access to the resource mailbox, you should be able to manipulate the calendar's permissions:Reviewer
access lets people see calendar events. I usually set this as the default permission, but you might want it to be different.- Give
Editor
access to users that should be able to change events in a calendar. In our example theRoom Delegates
group might be appropriate here, but be careful! If you have multiple delegates then you can run into problems.
There are a lot of other permission settings (Author
, Publishing
Author
) that look promising, but in fact are not worth fiddling with.
In Exchange 2007 with Outlook 2007,
neither Authors nor Publishing Authors can create appointments in a
Resource Mailbox's calendar by clicking in that calendar; when we try
we keep getting "Cannot open the free-busy information. You do not
have sufficient permissions" errors.
Permissions settings only take effect after the target users close and restart Outlook.
Resource Mailbox Bugs and Quirks
We have run into a lot of problems. Most of them have to do with manipulating appointments in the calendar interface:
Creating appointments in Resource Mailbox calendars is an all-or-nothing proposition. Either you have to be an Editor (which allows you to destroy everybody else's appointments) or you have to be a Reviewer (who can only view appointments). There is a way to twiddle permissions to allow Publishing Authors to create appointments, but this requires using a tool called "PFDAVAdmin".
In our experience, calendar manipulations are not tracked properly by the resource mailbox. For example, extending a booking by dragging the appointment does not (always?) prevent others from booking appointments during the time extension.
Most catastrophically, there appears to be a delay when Editors book appointments simultaneously using the calendar interface. It looks like you can get double-bookings. It also looks like you can get double-bookings when one person books using the calendar and another sends an appointment request via the scheduling assistant.
Setting Reviewer permissions on calendars is frustrating for users because they click on appointments other people have booked and get permissions errors.
It is not easy for people to set up bookings for events they won't attend. When you use the appointments/booking assistant interface to book an appointment, you are automatically added to the appointment. The only way I know of to make appointments you will not attend is to create the appointment in somebody else's calendar -- usually the resource mailbox's calendar, which is fraught with danger.
Booking rooms by adding them to the "Rooms" field of an appointment (as opposed to an "Attendee" or "Resources" field [CHECK]) does not work the way you expect -- the room's resource mailbox will NOT get an invitation to the meeting.
If you create an appointment by clicking on the Resource Mailbox's calendar, then the Resource Mailbox gets e-mail notification from people who accept and decline the meeting request, not you. You have to use the "Tracking" feature in Outlook 2007 to track such meeting attendees.
If you book a resource and all human participants decline, then the resource does not cancel the booking automatically.
Using PFDAVAdmin to Twiddle Permissions
This section is only for crazy people. If you really want to let Authors and Publishing Authors create appointments in the calendar of a Resource Mailboxes by clicking-and-dragging, you can manually fix the free-busy permissions for that mailbox.
To do this you need to download a utility called PFDAVAdmin.exe
. It
is a free download from Microsoft. Here are the steps to allow a
Publishing Author (let's say the Room Bookers
group) to click in a
calendar and create an appointment:
- Make sure
Room Bookers
is listed as havingPublishing Author
permissions on the calendar in question. - Start PFDAVAdmin.exe as an (Exchange?) administrator. Apparently you should avoid doing this on the same box as runs Exchange, or you get weird errors when trying to see the data. Here is a thread with more information.
- Choose
File -> Connect
. Enter your MS Exchange server and GAL server names (which might be the same). Select theAll Mailboxes
radio button. - Go to the mailbox you want to change. Expand it. Right-click "Freebusy Data" and choose "Folder Permissions".
- Add a permission. There is a complicated LDAP search box that comes
up. Typing the name of the account ("Room Bookers") and then clicking
Search
should work. - You should now see the "Room Bookers" group show up. Give this role
Publishing Author
privileges using the dropdown menu on the right. - You have to commit changes before quitting.
This fix is documented here: http://www.office-outlook.com/outlook-forum/index.php?t=msg&th=159117/