Free/Busy Data Demystified

To track users’ availability for meetings, Exchange Server and its clients use free/busy data—a mechanism that often causes angst for Exchange administrators. Few administrators understand how clients publish free/busy data as users update their calendars, where Exchange stores the data, and what the data actually represents. Although TechNet and the Exchange development team blog (at http://msexchangeteam.com/default.aspx) provide good information about free/busy data, this article aims to give you comprehensive coverage of the topic, bringing different sources of information together to illuminate one of the more esoteric parts of Exchange.

Let’s start demystifying free/busy data by looking at where Exchange stores it and how clients publish it. With that foundation, you can explore what the free/busy data represents, how Exchange and Outlook use it, and how you can use the Exchange Information Store Viewer to gain additional insight into the data. We’ll finish up with a look at some changes coming in Exchange Server 2007 that promise to give users the most current free/busy data available as they manage their calendars.

Where Free/Busy Data Resides
All pre–Exchange Server 2007 versions of Exchange use a public folder to store the data that clients use to calculate when users are available. Exchange Server 2003 and 2000 servers store free/busy data in the SCHEDULE+ FREE BUSYAdmin Group public folder. If your mailbox is on the Exchange server that belongs to the London administrative group, for example, your free/busy information is stored in the SCHEDULE+ FREE BUSYLondon public folder.

You can view free/busy folder details through the Exchange System Manager console by expanding the public folder root, as Figure 1 shows, then selecting the option from the right-click menu to view system folders. Exchange has one free/busy folder for each administrative group and one item in the folder for each mailbox in that administrative group. The data in the free/busy items is reasonably compact—approximately 100 bytes per user—so there’s not much server load involved in storing, managing, and replicating this data.

However, replication of free/busy data affects how current, and thus how accurate, the data is for users trying to schedule meetings. If your Exchange implementation stores only one copy of the free/busy information for a user, Outlook must connect to that folder on a specific server in the organization. If that server is close (in network terms), you’ll get acceptable performance and the free/busy data will be up-to-date and accurate. However, in a distributed organization, you might want to replicate free/busy data to several public folder servers so that users can access local copies of the data. This strategy would certainly improve performance, but because of a lag in replication, it could also yield outdated free/busy data when a user consults it to schedule a meeting.

Publishing Free/Busy Data
After a user updates his or her calendar, Outlook updates the user’s free/busy data in the public folder according to the user-specific options that Figure 2 shows. (You can access this screen from the Outlook Tools menu by clicking Options, Calendar.) The default setting is for Outlook to connect and update free/busy data every 15 minutes and to publish two months of calendar-availability data. Thus, if every user in the organization uses the default publication options, you won’t be able to see the availability of other users’ calendars past the next two months, even if they’ve scheduled meetings and other appointments past that time. You can publish as much as 36 months of free/busy data and update the server as often as every minute.

Outlook Web Access (OWA) users can update their free/busy data, but IMAP and POP clients don’t support this functionality. Exchange updates the data for OWA clients through the MSExchangeFBPublish process, which runs as part of the System Attendant service. When an OWA user updates his or her calendar, the Store processes the calendar data, then submits a message to the System Attendant mailbox on the server. A polling thread that runs inside the MSExchangeFBPublish process checks the System Attendant mailbox every five minutes to pick up free/busy messages and applies these updates to the public folder on behalf of the user. However, Exchange administrators can adjust the polling interval from every 30 seconds (the most frequent interval that you can set) upward. To change the polling interval, update or insert the PollingInterval registry key (a DWORD value) at HKLMSystem CurrentControlSet ServicesMSExchangeFBPublishParameters\{Server Name} (where {Server Name} is the physical server name or the virtual server name for clusters). You have to restart the System Attendant service for the new polling interval to take effect.

OWA doesn’t let users change the default publication settings for free/busy data, so all OWA clients publish two months of free/busy data by default. But because OWA inherits Outlook’s publishing settings, you can force OWA to change the publishing period by updating it through Outlook.

What the Data Means
Free/busy data identifies when users are occupied. However, the data is pretty basic and doesn’t contain information about why users aren’t available, such as whether they’re at a meeting or have a personal appointment, where the meeting or appointment is, or whether they’re in the office or traveling.

In addition, Exchange merges consecutive appointments together to form one chunk of busy time. Thus, when you view another user’s calendar and see that he or she is busy between 10am and 5pm, you can’t tell whether the user has one long appointment or several shorter meetings. And although the items in other users’ calendars might have different status settings, such as busy or tentative, Exchange shows any appointment that users create in their calendars as a busy timeslot.

Inside the item that holds a user’s free/busy data, you find records that represent chunks of occupied time. The format of the time chunk is represented by the number of minutes from the start of the month to the beginning of the chunk and from the start of the month to the end of the chunk. These two points in time are called the DTStart and DTEnd properties. Exchange stores all times in the Greenwich Mean Time (GMT) zone to ensure that meetings scheduled across time zones occur at the right time. Let’s assume you have an appointment booked on July 14, 2007, from 9am to 10am. GMT; Outlook would calculate the DTStart property as follows:
• From the start of the month (July 2007) to the end of the month is 31 days, or 44,640 minutes.
• The appointment start time is 13 days and nine hours (321 hours or 19,260 minutes) from the beginning of the month. A GMT offset applies if you aren’t in the GMT time zone.
• So, DTStart is 19,260 (the number of minutes from the start of the month), and DTEnd is 19,320. Outlook converts these values to hex, so DTStart is 4B3C, and DTEnd is 4B78.
• Outlook now calculates a value for the month (July 2007) by using the following algorithm: (Year*16) + number of month in year=Month—or (2007*16) + 7 = 32,119.
• The client now posts the following free/busy data—32,119 4B3C 4B78—in the item in the public folder.

However, updating free/busy information isn’t as simple as posting the new information to the public folder because the items in the free/busy date folder contain different types of records depending on the type of calendar entry the user made. For example, entries can be busy, out of the office, or tentative, and each type of data has its own prefix, as follows:
• 0X684F = merged month
•0X6850 = merged day
•0X6851 = tentative month
•0X6852 = tentative day
•0X6853 = busy month
•0X6854 = busy day
•0X6855 = out of office (OOF) month
•0X6856 = OOF day

For efficiency, Outlook also merges month and day data together where it can. If adjacent appointments overlap, Outlook merges them into a single record because they occupy the same timeslot. For example, suppose you have these appointments in your calendar:

Records 1, 2, and 4 are the same type (busy), so Outlook sorts them by start time before merging them into one record. After the merge, the record will contain two busy Start/End pairs: 10am to noon and 3pm to 5pm In addition, Outlook will have a Start/End pair for any tentative slots that occur in the schedule. Assuming that Outlook has only one piece of data for the occupied timeslot in the merged record, the data now looks like this:

0X684F 321190X6850 3C 4B 78 4B0X6853 319940X6854 3C 4B 78 4B

Because the free/busy data is reasonably complex, Outlook doesn’t try to merge new data into existing data. Instead, it deletes the user’s existing free/busy data and writes brand-new data that represents the current calendar state. Note that all versions of Outlook support the /cleanfreebusy switch to force the client to recalculate and republish free/busy information should the need arise. Using /cleanfreebusy can fix the problem if users can’t access free/busy data for some reason.

An Insight into the Data
The Exchange Information Store Viewer, MDBVU32 (available from www.microsoft.com), provides the best way to gain insight into the type of data the free/busy folder stores. When MDBVU32 starts, it asks for a profile. Any MAPI profile will do. To access the free/busy information, follow these steps:

As Figure 3 shows, the Messages in Folder pane now shows the items in the free/busy folder. You can select the free/busy information for a particular user by double-clicking the item for that user; you can then look at the item’s properties and so on.

The left screen in Figure 3 shows the records for each user, identified by a value based on the user’s LegacyExchangeDN property. Technically speaking, Exchange treats the item as a “note” (IPM.Note) and identifies the note through its subject, following the convention

USER-/CN=/CN=

For example, the free/busy item for my user account has a subject line of

USER-/CN=RECIPIENTS/CN=REDMOND

The screen on the right shows the properties of a selected user’s record (in this example, mine). You can see four 0X684F records for different months (32103 =July 2006, 32104 = August 2006, and so on) followed by some 0X6850 records for individual days. For more information about how to use the MDBVU32 program to interrogate free/busy data, see the Word document included in the MDBVU32 download.

Free/Busy in Exchange Server 2007
The public-folder model for free/busy storage and replication works reasonably well for Exchange 2003 and earlier, but Microsoft’s de-emphasis of public folders requires a new mechanism for Exchange 2007. The new Availability service, which runs only on Exchange 2007 servers that support the Client Access Server (CAS) role, makes the free/busy data maintained by Outlook 2007 and OWA 2007 clients available to other clients when users want to schedule a meeting.

Every Active Directory (AD) site that supports an Exchange 2007 mailbox server must also have a CAS. When clients need to read free/busy data to set up a meeting, the Availability service reads the necessary data directly from the calendar folders in user mailboxes for anyone who uses Outlook 2007 or OWA 2007. The Availability service can also access free/busy data from a public folder if your organization uses older clients.

Let’s look at an example of how the free/busy process works in Exchange 2007. Assume that you have an Outlook 2007 user connected to a mailbox server in London who wants to schedule a meeting with users located in San Francisco and New York. Each city has an AD site, and each AD site has an Exchange server.

To begin, Outlook connects to a CAS in the London AD site. In many cases, a CAS runs on the same Exchange server that hosts the user’s mailbox because an Exchange 2007 server can concurrently host the CAS, mailbox, and hub transport roles. The available CASs are published in the Exchange configuration data within AD, so if the site supports more than one CAS, the Availability service selects from the list of available servers by using a round-robin algorithm.

The CAS in the scheduling user’s site proxies the request for free/busy data across an HTTPS connection to a CAS in the AD sites that host the other users with whom you want to schedule a meeting, so separate requests go to CASs in San Francisco and New York. The CASs that receive the incoming requests are responsible for looking up the calendar data for the specified users and access either the user mailbox or a local copy of the public folder to retrieve this data. They then return the data through HTTPS to the original CAS, which collates the free/busy data and responds to the user who needs the information to schedule the meeting.

The big advantage of the new mechanism is that the data that the CAS returns to the user scheduling the meeting is guaranteed to be up-to-date. By contrast, the data you retrieve from the free/busy public folder might be inaccurate because of outages or time delays in public-folder replication.

On the downside, the scheduling user potentially might have to wait longer to see free/busy data because of the interserver communication required to fetch data from around the organization. After all, going to one place for your free/busy information (the local replica of the public folder) is much simpler than making a number of network connections. However, Microsoft is confident that it has optimized the way the CAS collects free/busy data and doesn’t expect users to notice much of a performance difference.

Of course, most organizations will deploy Outlook 2007 and Exchange 2007 over time, running in mixed mode for a number of years. So, Outlook 2007 and Exchange 2007 will continue to use the free/busy public folder for backward compatibility.

Mystery Solved
Free/busy information is an important feature for users who need to find available slots to schedule appointments in other users’ calendars. And now that you understand how the mechanism’s pieces fit together, you’ll be better able to manage free/busy data and troubleshoot any problems. Although Exchange 2007 will bring some improvements, especially in assuring up-to-date data, it’ll be a while before most organizations see the full impact of those changes.