Exchange Free / Busy message size

I saw this on an internal mail the othe day, and thought that this information was too good not to share around.  I only wish I’d had this level of detail available to me when I was an Exchange administrator.  So I’m sharing it.  Just in case you also want to know more … There’s a good document on TechNet that talks about how to Manage Free/Busy Folders  expecially on how Outlook handles Free/Busy but this is a nice edition to the document. 

If you want to change the amount of time published by Free/Busy – how much extra traffic would be generated?  Say for example you wanted to double the free busy schedule – how many bytes on the wire?  How large are the messages, and what would be the load on the free/busy server after the change had been made?

Jeffrey and Dave responded that you can get a good estimate by looking at the current PR_MESSAGE_SIZE and PR_CONTENT_COUNT values of the Schedule+ Free Busy folder for the site or Administrative Group.  You’ll then have to divide the size by the count to get a per user average.  Assuming that user’s currently have the default setting of 6 months, you can extrapolate the impact of changing the number of months published.
For example, in the sample  F/B folder:
PR_MESSAGE_SIZE = 18,499,128
Based on this calculation, the average free/busy message size is approximately1119 bytes.

Free Busy data is pretty small.  The data is stored as an array of pairs 16-bit words – each being the number of minutes into the month for the beginning and end time of each busy range. The maximum number of busy ranges can be forced by making every other minute in the month busy. 1440 minutes in a day, 720 marks every other one. 31 days in a month… leads to just shy of 90k per month in the worst possible case. Actual values will be substantially smaller than that. As more calendars get more and more booked, the amount of data stored actually goes down as the busy ranges get merged together.
The Free Busy server will experience pretty much the same load overall (“Open message, stream in data, close message”). The extra data is likely going to cause maybe one extra RPC operation. Also if you’re replicating the Free/Busy data to another Public Folder server, it’ll double the amount of replication traffic.