Public Free/Busy file

OWA's free/busy data is generated from the data in /public/NON_IPM_SUBTREE/SCHEDULE%2B%20FREE%20BUSY/. Under that directory, there is a directory for each Exchange organization. Eg:

In that directory is a file for each user, eg:

So, given that my legacyExchangeDN is

you can find my public free/busy file. ("_xF8FF_" is the URI-encoded form of '/' when it's not a path separator. e2k_uri_encode handles this.). The legacyExchangeDN is also stored as the PR_FREEBUSY_EMAIL_ADDRESS property on the message, so we can also just search for that.

The PR_FREEBUSY_START_RANGE and PR_FREEBUSY_END_RANGE properties on this message give the start and end times of the published range, in systime (minutes since 16010101T00000000Z) format. These always fall on month boundaries. (The start time is always the beginning of the current month, and the end time is determined by the PR_FREEBUSY_NUM_MONTHS property on the private free/busy file (described below).)

Four pairs of multivalued properties give the actual free/busy data.

The _MONTHS properties are arrays of

struct {
	guint month:4;	/* 1 = January */
	guint year :28;
};

Each element of this array has a corresponding element in the _EVENTS array containing the events in that month and year as an array of:

struct {
	guint16 start;	/* minutes since start of month */
	guint16 end;	/* minutes since start of month */
};

If there are no events of a given type in the given interval, then Outlook leaves the two properties for that type unset. (If there are no events at all, then all 8 properties will be unset.) But when Exchange regenerates them itself, it just creates them empty instead.

Additionally, several other properties are used:

There is also one more property, http://schemas.microsoft.com/mapi/string/{8CDA1CAE-AFDB-11D2-9379-00C04FA357AA}/microsoft.cdo.calendar.fbhistory, of type PT_MV_BINARY, which seems to always contain 3 24-byte items. The first two bytes of each are a month-year like the _MONTHS properties (and for an up-to-date free/busy file, the 3 items will be this month, next month, and the month after). There are then 6 0 bytes, followed by 8 bytes of data that are almost always the same in each of the 3 items, followed by 8 0 bytes. The purpose of this data is currently unknown. The middle chunk of data seems to get changed every time the free/busy data is updated. It may be a timestamp of some unknown sort?

Personal Free/Busy file

Each user also has a personal free/busy message, at:

This is known to be used for at least three things:

When you create an event via WebDAV, the server will eventually update the free/busy file with that data, but this is subject to various delays and exceptions that we don't understand. Among other things, Outlook uses the free/busy file to decide what dates to make bold in the minicalendar, which is why Connector-created appointments don't always show up there right away even when Outlook does display the event itself.

The free/busy data is stored in the PR_PERSONAL_FREEBUSY property as follows:

struct {
	guint32 magic;		/* 0xdeadbeef */
	guint32 header_len;	/* 0x00000040 */
	guint32 unknown_1;	/* 0x00010000 */
	guint32 unknown_2;	/* 0x00000000 */

	guint32 num_groups;	/* number of free/busy groups */
	guint32 num_events;	/* total number of free/busy objects */
	guint32 unknown_3;	/* 0x00000008 */
	guint32 unknown_4;	/* 0x00000004 */

	guint64 first_event;	/* Windows filetime of start of first event */
	guint64 last_event;	/* Windows filetime of end of last event */
	guint64 start_valid;	/* Windows filetime of start of range */
	guint64 end_valid;	/* Windows filetime of end of range */

	struct {
		guint32 index;	/* Index of first event belonging to this group */
		guint32 count;	/* Number of events in this group */
	} groups[num_groups];

	struct {
		guint32 offset;	/* Offset in minutes of event from start of group */
		guint len:13;	/* Length of event in minutes */
		guint status:3;	/* Status (1 = tentative, 2 = busy, 3 = oof) */
	} events[num_events];
};

The first group starts at the time indicated by start_valid, so an event in group 0 with an offset of 0 starts at start_valid. Group N starts at time (start_valid + N * 0x10000). If there are no events in the timeframe of a group, its index and count will both be 0.

There is no particular correlation between free/busy events and events on the calendar: two adjacent calendar events can be stored as a single free/busy event, and a given calendar event may be split across two or more free/busy groups.

The number of months covered by the free/busy data is in PR_FREEBUSY_NUM_MONTHS.

A posting on the MAPI-L list claimed that setting PR_DISABLE_FULL_FIDELITY to 0 on the free/busy message will force Outlook to regenerate it, but I haven't tested this.