Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

Microsoft Exchange Server 2013 : Mailbox management - Resource mailboxes (part 1) - Providing policy direction to the Resource Booking Attendant

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
12/3/2014 3:06:04 AM
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.

The result of selecting the All Rooms address list when browsing the address book in Outlook is that you see a list of all the room mailboxes that exist within the organization.

Figure 1. Viewing room mailboxes in the GAL

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* -AutoSize

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

A screen shot of the Booking Options properties of a room mailbox. This room allows repeating meetings to be scheduled and meetings to be scheduled outside working hours. The maximum lead time is 180 days in advance.

Figure 2. Viewing the booking options for a room mailbox

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.

Inside Out Handling the effects of simplification

Even though EAC presents a more simplified view of calendar processing properties than is visible through the Exchange 2010 EMC, you should not assume that anything has really changed in the background. All the properties are still respected by the Resource Booking Attendant and can be manipulated through EMS. So even if you have built the most complex room-booking scheme possible using Exchange 2010, you can be safe in the knowledge that Exchange 2013 will continue to process meeting requests as before, even if it doesn’t quite reveal this fact.

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.

An example of a rejection message issued to a user when she attempted to schedule a meeting in a room too far in advance. In this instance, she attempted to schedule a date 190 days away when the room is configured with a maximum lead time of 180 days.

Figure 3. A meeting request declined by the Resource Booking Attendant

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.

Inside Out Meeting room conflicts

In real life, the most senior person will get to hold his meeting in the room, but because Exchange is unaware of company structure and politics, all it can do is allow you to define whether conflicting requests are accepted or immediately declined and, if accepted, how many conflict instances are permitted for a time slot. It would be silly to allow an unlimited number of conflicts to be scheduled because this would create some interesting situations when multiple teams turn up in the same place at the same time for their meeting. It might be acceptable to allow one or two conflicts if you have someone who checks the room’s calendar from time to time to introduce some human intelligence into the conflict resolution algorithm.

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'
Other -----------------
- Microsoft Exchange Server 2013 : Mailbox management - Mail-enabled contacts, Mail users
- Microsoft Exchange Server 2013 : Mailbox management - Moderated recipients (part 2) - Processing moderation requests, Moderated mailboxes
- Microsoft Exchange Server 2013 : Mailbox management - Moderated recipients (part 1) - Moderated groups
- Microsoft Exchange Server 2013 : Mailbox management - Shared mailboxes , Recalling messages
- SQL Server 2012 : Transact-SQL - Functions, Triggers
- SQL Server 2012 : Transact-SQL - Stored Procedures
- SQL Server 2012 : Transact-SQL - Transactions
- SQL Server 2012 : Transact-SQL - Data Manipulation Language (part 2)
- SQL Server 2012 : Transact-SQL - Data Manipulation Language (part 1)
- SQL Server 2012 : Transact-SQL - The VetClinic Sample Database Revisited, Data Types
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server