Paul's Internet Landfill/ 2011/ Exchange 2007 Resource Mailboxes

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):

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.

  1. Exchange 2007 Resource Mailboxes
    1. Mailbox Setup
      1. Setting up Groups
      2. Creating Mailboxes
      3. Configuring Mailbox Access
      4. Configuring Booking Policy
      5. Setting Working Hours
      6. Setting Calendar Permissions
    2. Resource Mailbox Bugs and Quirks
    3. Using PFDAVAdmin to Twiddle Permissions
  2. Sidebar!

Mailbox Setup

Configuring a resource mailbox involves the following steps:

  1. Setting up groups that will be able to interact with the mailboxes.
  2. Creating the mailbox in Exchange Management Console (EMC) or Powershell.
  3. Configuring the mailbox access options using Powershell.
  4. Configuring the "booking policy", which specifies who may interact with the resource mailbox and under what conditions. This involves Powershell.
  5. Setting the mailbox's working hours, which requires Outlook or Outlook Web Access under Internet Explorer.
  6. 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:

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:

Creating the mailboxes in EMC is not hard:

  1. Create a new mailbox
  2. Designate it as a room or equipment mailbox
  3. Change the organizational unit. My LDAP tree has a folder called Exchange Resources, so I put resource mailboxes there.
  4. 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.
  5. 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:

I tend to focus on the following properties:

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.

  1. 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.

  2. 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 .

  3. 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.

  1. Start Outlook as a member of Booking Admins, which have full access to the resource mailbox.

  2. Click on Calendars and then go File -> Open -> Other User's Folder . Click Name to browse the user list, and find the calendar. The folder type should be calendar. This should open up the resource mailbox's calendar under "Other People's Calendars" [CHECK]

  3. In the calendar list, right-click the calendar and choose Properties, then choose the Permissions tab. As a user with full access to the resource mailbox, you should be able to manipulate the calendar's permissions:

  4. Reviewer access lets people see calendar events. I usually set this as the default permission, but you might want it to be different.
  5. Give Editor access to users that should be able to change events in a calendar. In our example the Room 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:

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:

  1. Make sure Room Bookers is listed as having Publishing Author permissions on the calendar in question.
  2. 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.
  3. Choose File -> Connect. Enter your MS Exchange server and GAL server names (which might be the same). Select the All Mailboxes radio button.
  4. Go to the mailbox you want to change. Expand it. Right-click "Freebusy Data" and choose "Folder Permissions".
  5. 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.
  6. You should now see the "Room Bookers" group show up. Give this role Publishing Author privileges using the dropdown menu on the right.
  7. You have to commit changes before quitting.

This fix is documented here: