Resource Mailboxes in Exchange 2010 Introduction Many organizations that I have come across that have implemented Exchange have found the need to create mailboxes that represent resources, such as conference rooms or equipment items such as whiteboards, projectors and so on. By creating such resources, users can then book them via the calendaring feature of Exchange in much the same way that they would book fellow attendees, thereby reserving the resource item for their use. In versions of Exchange prior to Exchange 2007, the overall resource mailbox process was not quite as smooth as it could be. For example, in Markus Klein s article on MSExchange.org, you will see that it was possible to use public folders for resources although this had one or two drawbacks such as a lack of free/busy information being presented in the calendar. If a mailbox was created for the resource, the main administration topic focused on who would monitor the resource bookings. For example, if two people booked the same meeting room, would the first person to request the room be granted the booking? Or would the most senior person be granted the booking? The Auto Accept Agent helped in this area as it was used to automatically process meeting request for resource mailboxes. With Exchange 2007 and Exchange 2010, a new approach to resources has been made. Exchange 2007 and Exchange 2010 support automatic booking of resource mailboxes, meaning that tools like the Auto Accept Agent are no longer required. Starting with Exchange 2007, resource mailboxes had, for the first time, specific Active Directory attributes that related to the use of resources, such as an attribute that specified the number of people that a meeting room could hold. This model is largely the same in Exchange 2010 and it is Exchange 2010 and Outlook 2010 that I am going to focus on in this article series. So let s get going and take a look at resource mailboxes in Exchange 2010. Creating Resource Mailboxes Creating resource mailboxes is very easy and can be done using either the Exchange Management Console or the Exchange Management Shell. In the Exchange Management Console, creating a resource mailbox is much the same process as creating a new user mailbox. When clicking the New Mailbox action in the action pane the administrator is presented with the screen shown in Figure 1, you can see the options to create either a room mailbox or an equipment mailbox.
Figure 1: Creating a Room or Equipment Mailbox One of the interesting things to note regarding resource mailboxes is that the associated Active Directory user account is automatically disabled as indicated by the text shown in Figure 1. For example, in Figure 2 it can be seen that a new room resource mailbox Active Directory user account is being created for Conference Room A. If you look closely at the user account icon in Figure 3, it can be seen that the associated Active Directory user account is automatically disabled once it has been created. This raises an interesting point if you pre-create an Active Directory account and then use the Exchange Management Console to mailbox-enable this Active Directory account with a resource mailbox. Remember to disable the Active Directory account that you pre-create, otherwise it will not show up in the Exchange Management Console as a valid account to mailbox-enable as a resource mailbox.
Figure 2: Creating the Associated Active Directory User Account Figure 3: Disabled Active Directory User Account
It is also possible to use the Exchange Management Shell to create a resource mailbox via the New-Mailbox cmdlet. For example, to create the room resource mailbox for Conference Room B via the Exchange Management Shell, the following command can be used: New-Mailbox -Name 'Conference Room B' -Alias 'ConfRoomB -UserPrincipalName 'ConfRoomB@neilhobson.com' -FirstName 'Conference' -LastName 'Room B' Room The results of running this command can be seen in Figure 4. Note that this command doesn t specify the name of the mailbox database in which to store the resource mailbox as the system has been allowed to choose a database at random. If it is a requirement to create this mailbox on a particular database, the Database parameter of the New-Mailbox cmdlet can be used. Additionally, this command also doesn t specify an organizational unit in which to store the user account so the default Users container will be used. If you need to specify a different organizational unit, then use the OrganizationalUnit parameter, an example of which is shown below: -OrganizationalUnit 'neilhobson.com/resource Mailboxes' Figure 4: Creating a Resource Mailbox via the Exchange Management Shell It can be seen from the New-Mailbox cmdlet shown above that the key parameter used to identify this mailbox as a resource mailbox is the Room parameter right at the end of the command. This obviously informs the system that the resource mailbox being created is a room rather than the other type of resource mailbox available, the equipment mailbox. To create a resource mailbox for equipment, the Equipment parameter is used rather than the Room parameter. For example, the following command can be used to create a resource mailbox for a projector that belongs in Conference Room B: New-Mailbox -Name 'Projector Room B' -Alias 'ProjRoomB' -UserPrincipalName 'ProjRoomB@neilhobson.com' -FirstName 'Projector' -LastName 'Room B' -Equipment If the list of mailboxes is now displayed in the Exchange Management Console, it can be seen that the room and equipment resource mailboxes have different icons and recipient type details as can be seen in Figure 5.
Figure 5: Room and Equipment Resource Mailboxes By using the Room and Equipment parameters of the New-Mailbox cmdlet, additional property tabs will be seen when bringing up the properties of a resource mailbox. Specifically, the Resource General, Resource Policy, Resource Information, Resource In-Policy Requests and Resource Out-of-Policy Requests tabs will be seen as shown in Figure 6.
Figure 6: The Resource Mailbox Tabs Here is a brief description of the purpose of each of these tabs. Note that we ll be looking deeper at these configuration elements as we go through this article series. Resource General - This tab allows you to configure resource custom properties as well as the resource capacity value. Additionally, it is on this tab that you configure whether you enable the Resource Booking Attendant for this mailbox or not. Resource Policy - The Resource Policy tab allows you to configure specific policies that apply to the resource mailbox, such as whether repeating meetings can be booked and the maximum duration of a meeting. Additionally, you can configure resource mailbox delegates from this tab. Resource Information - This tab controls the meeting information that is available in the resource mailbox s calendar, such as attachments, comments, subject and so on. It also allows for the configuration of additional text sent to the meeting organizer.
Resource In-Policy Requests - Here you can configure those users who are allowed to submit in-policy meeting requests, which can be either automatically approved or approved by a resource mailbox delegate. Resource Out-of-Policy Requests - This tab allows you to configure those users who are allowed to submit out-of-policy meeting requests which need to be approved by a resource mailbox delegate. Introduction Many organizations that I have come across that have implemented Exchange have found the need to create mailboxes that represent resources, such as conference rooms or equipment items such as whiteboards, projectors and so on. By creating such resources, users can then book them via the calendaring feature of Exchange in much the same way that they would book fellow attendees, thereby reserving the resource item for their use. In versions of Exchange prior to Exchange 2007, the overall resource mailbox process was not quite as smooth as it could be. For example, in Markus Klein s article here on MSExchange.org, you will see that it was possible to use public folders for resources although this had one or two drawbacks such as a lack of free/busy information being presented in the calendar. If a mailbox was created for the resource, the main administration topic focused on who would monitor the resource bookings. For example, if two people booked the same meeting room, would the first person to request the room be granted the booking? Or would the most senior person be granted the booking? The Auto Accept Agent helped in this area as it was used to automatically process meeting request for resource mailboxes. With Exchange 2007 and Exchange 2010, a new approach to resources has been made. Exchange 2007 and Exchange 2010 support automatic booking of resource mailboxes, meaning that tools like the Auto Accept Agent are no longer required. Starting with Exchange 2007, resource mailboxes had, for the first time, specific Active Directory attributes that related to the use of resources, such as an attribute that specified the number of people that a meeting room could hold. This model is largely the same in Exchange 2010 and it is Exchange 2010 and Outlook 2010 that I am going to focus on in this article series. So let s get going and take a look at resource mailboxes in Exchange 2010. Creating Resource Mailboxes Creating resource mailboxes is very easy and can be done using either the Exchange Management Console or the Exchange Management Shell. In the Exchange Management Console, creating a resource mailbox is much the same process as creating a new user mailbox. When clicking the New Mailbox action in the action pane the administrator is presented with the screen shown in Figure 1, you can see the options to create either a room mailbox or an equipment mailbox.
Figure 1: Creating a Room or Equipment Mailbox One of the interesting things to note regarding resource mailboxes is that the associated Active Directory user account is automatically disabled as indicated by the text shown in Figure 1. For example, in Figure 2 it can be seen that a new room resource mailbox Active Directory user account is being created for Conference Room A. If you look closely at the user account icon in Figure 3, it can be seen that the associated Active Directory user account is automatically disabled once it has been created. This raises an interesting point if you pre-create an Active Directory account and then use the Exchange Management Console to mailbox-enable this Active Directory account with a resource mailbox. Remember to disable the Active Directory account that you pre-create, otherwise it will not show up in the Exchange Management Console as a valid account to mailbox-enable as a resource mailbox.
Figure 2: Creating the Associated Active Directory User Account Figure 3: Disabled Active Directory User Account
It is also possible to use the Exchange Management Shell to create a resource mailbox via the New-Mailbox cmdlet. For example, to create the room resource mailbox for Conference Room B via the Exchange Management Shell, the following command can be used: New-Mailbox -Name 'Conference Room B' -Alias 'ConfRoomB -UserPrincipalName 'ConfRoomB@neilhobson.com' -FirstName 'Conference' -LastName 'Room B' Room The results of running this command can be seen in Figure 4. Note that this command doesn t specify the name of the mailbox database in which to store the resource mailbox as the system has been allowed to choose a database at random. If it is a requirement to create this mailbox on a particular database, the Database parameter of the New-Mailbox cmdlet can be used. Additionally, this command also doesn t specify an organizational unit in which to store the user account so the default Users container will be used. If you need to specify a different organizational unit, then use the OrganizationalUnit parameter, an example of which is shown below: -OrganizationalUnit 'neilhobson.com/resource Mailboxes' Figure 4: Creating a Resource Mailbox via the Exchange Management Shell It can be seen from the New-Mailbox cmdlet shown above that the key parameter used to identify this mailbox as a resource mailbox is the Room parameter right at the end of the command. This obviously informs the system that the resource mailbox being created is a room rather than the other type of resource mailbox available, the equipment mailbox. To create a resource mailbox for equipment, the Equipment parameter is used rather than the Room parameter. For example, the following command can be used to create a resource mailbox for a projector that belongs in Conference Room B: New-Mailbox -Name 'Projector Room B' -Alias 'ProjRoomB' -UserPrincipalName 'ProjRoomB@neilhobson.com' -FirstName 'Projector' -LastName 'Room B' -Equipment If the list of mailboxes is now displayed in the Exchange Management Console, it can be seen that the room and equipment resource mailboxes have different icons and recipient type details as can be seen in Figure 5.
Figure 5: Room and Equipment Resource Mailboxes By using the Room and Equipment parameters of the New-Mailbox cmdlet, additional property tabs will be seen when bringing up the properties of a resource mailbox. Specifically, the Resource General, Resource Policy, Resource Information, Resource In-Policy Requests and Resource Out-of-Policy Requests tabs will be seen as shown in Figure 6.
Figure 6: The Resource Mailbox Tabs Here is a brief description of the purpose of each of these tabs. Note that we ll be looking deeper at these configuration elements as we go through this article series. Resource General - This tab allows you to configure resource custom properties as well as the resource capacity value. Additionally, it is on this tab that you configure whether you enable the Resource Booking Attendant for this mailbox or not. Resource Policy - The Resource Policy tab allows you to configure specific policies that apply to the resource mailbox, such as whether repeating meetings can be booked and the maximum duration of a meeting. Additionally, you can configure resource mailbox delegates from this tab. Resource Information - This tab controls the meeting information that is available in the resource mailbox s calendar, such as attachments, comments, subject and so on. It also allows for the configuration of additional text sent to the meeting organizer.
Resource In-Policy Requests - Here you can configure those users who are allowed to submit in-policy meeting requests, which can be either automatically approved or approved by a resource mailbox delegate. Resource Out-of-Policy Requests - This tab allows you to configure those users who are allowed to submit out-of-policy meeting requests which need to be approved by a resource mailbox delegate. Resource Booking Attendant Having human intervention is obviously fine if you have delegates that are willing and able to perform all of the required work associated with resource mailboxes. However, Exchange also offers the ability to automate some of the resource booking process. For example, what if you desired a configuration where senior management could always automatically book a meeting room without requiring the approval via a delegate? That s where the Resource Booking Attendant comes in. With that in mind, let s now enable the Resource Booking Attendant for a room resource mailbox and automate the conference room bookings; this is performed on the Resource General tab of the resource mailbox properties. Note that the highlighted area in Figure 18 also includes the text that explains that the resource booking settings are only effective when the Enable the Resource Booking Attendant check box has been selected. These resource booking settings are those found on the Resource In-Policy Requests, Resource Out-of-Policy Requests and Resource Policy tabs as we shall see later in this article.
Figure 18: Enabling the Resource Booking Attendant To enable the Resource Booking Attendant using the Exchange Management Shell, use the Set- CalendarProcessing cmdlet and specify a value of AutoAccept for the AutomateProcessing parameter. For example, to configure Conference Room A such that the Resource Booking Attendant is enabled, the following command will be used: Set-CalendarProcessing Identity ConfRoomA AutomateProcessing AutoAccept In this example, the AutomateProcessing parameter is set to AutoAccept; the default setting is AutoUpdate, whilst the other available option is None. The setting of AutoUpdate means that the Calendar Attendant is used on the resource mailbox, which itself means that new meeting requests will be marked as tentative on the resource mailbox calendar. Resource Policy
When examining the properties of a resource mailbox in the Exchange Management Console, you will see tabs labeled Resource In-Policy Requests and Resource Out-of-Policy Requests. Before we get into the specifics of discussing the configuration of both of these tabs, you might be wondering exactly what in-policy and out-of-policy requests actually are, so we shall discuss these now. To understand in-policy and out-of-policy requests, it is useful to examine the contents of the Resource Policy tab on a resource mailbox s properties. The Resource Policy tab for the resource mailbox called Conference Room C is shown in Figure 19. In fact, you might remember that this tab was shown in Figure 14 in part 2 of this article series when we were discussing how to configure delegates for the resource mailbox. Note that the values shown in Figure 19 are the default values assigned when a resource room mailbox is first created. Figure 19: Resource Policy Tab Default Settings The Resource Policy tab allows you to configure various settings that control whether or not certain users are allowed to automatically book meetings based on the characteristics of the meeting request itself.
Many of the settings that you can see in Figure 19 should be self-explanatory from the descriptions. For example, the Allow conflicting meeting requests option means exactly that. If you allow conflicting meetings, any conflicting meeting requests will be accepted by the resource mailbox and it will be up to the meeting organizers to work things out. The Booking windows (days) option covers how far in advance users can book this meeting room and as you can see the default setting is 180 days which is approximately 6 months. If you want to effectively disable any advance booking restrictions, simply set this value to 0. The Maximum duration (minutes) option covers how long the meeting request is allowed to last. As you can see, the default value for this option is 1440 minutes which equates to 1 day. This will probably suffice in the majority of situations for a room resource mailbox but should any of your users need to book the room resource for more than 1 day you will need to alter this value here. You can control the policy for conflicting meeting requests via the Maximum conflict instances and Conflict percentage allowed options. All of the settings shown in Figure 19 can be set via the Set-CalendarProcessing cmdlet. Table 1 below shows the parameter names used in the Exchange Management Shell. I created this table by using one of the cool new features found in the Exchange Management Console in Exchange 2010. If you look back at Figure 19 you can see the show Exchange Management Shell command button in the bottom-left corner of the properties screen for Conference Room C. Clicking this button after making a change in the Exchange Management Console will show you the corresponding Exchange Management Shell command. An example is shown in Figure 20 where you can see the results of changing the Allow conflicting meeting requests option in the Exchange Management Console. Figure 20: Showing the Exchange Management Shell Command Used Configuration Name Allow conflicting meeting requests Allow repeating meetings Set-CalendarProcessing Parameter AllowConflicts AllowRecurringMeetings
Allow scheduling only during working hours Reject repeating meetings that have an end date beyond the booking window Booking window (days) Maximum duration (minutes) Maximum conflict instances Conflict percentage allowed Specify delegates of this mailbox Forward meeting requests to delegates ScheduleOnlyDuringWorkHours EnforceSchedulingHorizon BookingWindowInDays MaximumDurationInMinutes MaximumConflictInstances ConflictPercentageAllowed ResourceDelegates ForwardRequestsToDelegates Table 1: Resource Policy Tab Cmdlet Parameters Additionally these settings, together with some additional settings that will be covered later in this article, can be found within Outlook Web App (OWA) when accessing the resource mailbox. For example, look at Figure 21 where you can see the resource options for the Conference Room D resource mailbox. This particular page is accessed via the Exchange Control Panel (ECP) in OWA. Specifically, in OWA click Options then See All Options which will take you to the ECP. Here click the Settings option on the left-hand side of the screen and you will be presented with the screen shown in Figure 21. Note that the Resource tab is only seen when a resource mailbox is accessed in OWA. Figure 21: OWA Resource Tab
The settings shown in Figures 19 and 21 form the resource mailbox policy and therefore if a meeting request does not conflict with any of these settings, it is an in-policy meeting request. If a meeting request does conflict with any of these settings, it is an out-of-policy meeting request. You can control what happens to in-policy or out-of-policy meeting requests on a per-user basis by configuring the options on the Resource In-Policy Requests and Resource Out-of-Policy Requests tabs. We ll be doing exactly that in the fourth and final part of this article series. How Resource Policies Affect Users By default, all users can submit in-policy meeting requests as you can see from Figure 22. You will also see that by default no users are configured to require their in-policy meeting requests to be approved by a delegate. On the Resource Out-of-Policy tab, the default setting is that no users are configured to be allowed to submit out-of-policy meeting requests that require approval by a delegate. Figure 22: In-Policy Requests Default Settings
Let s now look at how these settings affect the user experience, starting with the in-policy meeting requests. Take the scenario shown in Figure 23 where Neil s in-policy meeting requests are automatically approved but John s in-policy meeting requests have to be approved by a delegate. Figure 23: Configuring In-Policy Requests If Neil now books this room resource mailbox, he receives an automatically generated acceptance notification since he is allowed to automatically book this meeting room. You can see the results of this action in Figure 24. Note, that OWA has been used in this example.
Figure 24: Automatically Accepted Meeting Request However, if John books this same room resource mailbox, he will receive a tentative response indicating that his meeting request was received by the room resource mailbox, but is pending approval. This message is shown in Figure 25.
Figure 25: Meeting Request Pending Approval The room resource mailbox delegate will receive John s meeting request and will therefore have to decide whether or not John is allowed to book the resource. In this particular case, Sally is configured as the room resource mailbox delegate and you can see the meeting request approval message in Sally s Outlook 2010 inbox in Figure 26.
Figure 26: Delegate Approval Process Had John not been configured to have his meeting requests send to the delegate, he would have received a declined meeting request response from the room resource mailbox since he would not have permissions to book this particular room resource. To configure the in-policy requests that you saw in Figure 23 using the Exchange Management Shell, use the BookInPolicy and AllBookInPolicy parameters of the Set-CalendarProcessing cmdlet. If you want all users who submit in-policy meeting requests to have those meeting requests automatically approved, set the AllBookInPolicy parameter to true. Conversely, to select a specific set of users who require automatic approval, set the AllBookInPolicy parameter to false and then specify a list of users for the BookInPolicy parameter. The same principles apply for the settings that control whether in-policy meeting requests require approval by the resource mailbox delegate, although this time the two parameters are RequestInPolicy and AllRequestInPolicy. Even though users may be configured to automatically book in-policy meeting requests, or perhaps have their meeting requests approved by resource mailbox delegates, this does not necessarily mean that they are allowed to submit out-of-policy meeting requests. As we discussed earlier in this article, no users are allowed to submit out-of-policy meeting requests by
default. Let s take the maximum meeting time as an example, which you may remember is set to 1 day by default. Even though a user may be allowed to automatically book in-policy meeting requests, Figure 27 shows what happens if that user attempts to book a meeting that lasts longer than 1 day and thus is classed as an out-of-policy meeting request. Figure 27: Declined Out-of-Policy Request In Figure 27 you can clearly see that the meeting request was declined since the meeting request exceeded the overall duration limit of 1440 minutes, or 1 day. By adding the user to the configuration in the Resource Out-of-Policy Requests tab, out-of-policy requests such as this would be sent to the resource mailbox delegate for approval rather than being declined outright by the Resource Booking Attendant. Resource Information There is one final tab on the properties of a resource mailbox that we have yet to look at, and that is the Resource Information tab. This particular tab is shown in Figure 28, where you can see that many of the configurable options are self-explanatory. Setting these options will allow you to control the functionality and security of the resource mailbox. For example, users quite often include attachments in meeting requests and these can add to the overall mailbox size for the
resource mailbox. Therefore, having an automated way to remove these attachments will help control the mailbox size and this is what the Delete attachments option can be used for. Figure 28: The Resource Information Tab Settings One interesting configuration option that you may have noticed from Figure 28 is the additional text that you can add to customize the response message that the meeting organizer will receive. This text is added to all meeting responses and an example of how this text is seen within a meeting response is shown below in Figure 29.
Figure 29: Customized Text Example As we ve seen throughout this article series, the various configuration elements of a resource mailbox can be managed in the Exchange Management Shell via the Set-CalendarProcessing cmdlet and the options shown in Figure 28 are no different. Table 2 below shows the parameter names used in the Exchange Management Shell. As per Table 1 in part three of this article series, I created this table by examining the Exchange Management Shell command produced as a result of setting the options within the Exchange Management Console. Configuration Name Set-CalendarProcessing Parameter Delete attachments DeleteAttachments Delete comments DeleteComments Delete the subject DeleteSubject Delete non-calendar items DeleteNonCalendarItems Add the organizer s name to the subject AddOrganizerToSubject Remove the private flag on an accepted RemovePrivateProperty meeting Send organizer information when a OrganizerInfo meeting request is declined because of
conflicts Add additional text Additional text Mark pending requests as Tentative on the calendar AddAdditionalResponse AdditionalResponse TentativePendingApproval Table 2: Exchange Management Shell Parameters for the Resource Information Tab Room List Distribution Groups Exchange 2010 includes a fantastic new feature called room list distribution groups. This feature is designed to help the user in scenarios where the calendars of multiple resource mailboxes must be examined when attempting to find a vacant slot in a resource mailbox calendar. To make finding this vacant slot much easier, room list distribution groups can be created. Unfortunately it s not possible to use the Exchange Management Console to create a room list distribution group; you have to use the Exchange Management Shell. The cmdlet to use is the New- DistributionGroup cmdlet just as you would when creating a new ordinary distribution group. However, with room list distribution groups the key thing to remember is to include the RoomList parameter when using the New-DistributionGroup cmdlet. For example, to create a room list distribution group called Meeting Rooms that comprises the resource mailboxes for Conference Room A, Conference Room B, Conference Room C and Conference Room D the following command can be used: New-DistributionGroup Name Meeting Rooms Members ConfRoomA,ConfRoomB,ConfRoomC,ConfRoomD RoomList Figure 30 shows an extract of the Exchange Management Console after the room list distribution group has been created. Figure 30: New Room List Distribution Group Once the room list distribution group has been created it is available for users to select when composing a new meeting request in Outlook. In Figure 31, you can see the Show a room list option as highlighted within the red box. The user can select the room list distribution group
from a drop-down list and when this is done, the resource mailboxes that are members of this room list distribution group are populated within the calendar scheduling assistant as resource mailboxes. Immediately below the room list drop-down box you will note the Choose an available room selection area which has been highlighted in the blue box. This area contains suitable resource mailbox choices from the room list distribution group based on the availability of those resources. As you can see from Figure 31, Conference Room D is not available at the chosen meeting time which means it is not available as a selection in the Choose an available room selection area of the screen. Figure 31: Room List Distribution Groups in Outlook Summary We have reached the end of this article series on resource mailboxes in Exchange 2010. There is no doubt that this type of mailbox is extremely beneficial to almost all organizations that run Exchange and the functionality provided out of the box has got progressively better with each release of Exchange.