One way to deal with this problem is to configure every Outlook client to publish the same number of months of free/busy data. The Microsoft article "XCLN: How to Configure Default Free/Busy Options" (http://support.microsoft.com/?kbid=197712) describes the registry keys that store the publication interval. This article was written a while ago, so it doesn't give information for newer versions of Outlook. The registry keys in Outlook XP (and later) are the same as those in Outlook 2000. In addition, although the article states that the maximum number of months is 12, the upper limit is now 36 for Outlook XP and later. No matter the Outlook version, the publication interval must be in hexadecimal form (e.g., 0x0C for 12 months, 0x18 for 24 months).
The choice of which publication interval is best for you depends on your environment. Before choosing the publication interval, one of my customers wanted to know how the publication interval would impact storage space in its Exchange enterprise. The customer had more than 22,000 Exchange mailboxes, 11,616 of which published free/busy maps. In the largest administrative group, there were about 2800 mailboxes, 2577 of which published free/busy maps. (About 450,000 appointments were spread over those 2577 mailboxes, so as you might have guessed, this customer was in the government sector.)
To begin, I decided to determine how much storage space the free/busy data typically consumed based on the number of months published. So, I used a script to examine the LocalFreebusy message for the 2577 mailboxes in the largest administrative group. Table 1 shows the results. On average, the 2577 mailboxes used 2.3MB of storage space for the free/busy maps.
Using the information in Table 1 as a basis, I then estimated the storage utilization if the customer were to standardize the publication interval at 12 months, 24 months, and 36 months. As Table 2 shows, publishing 12 months of free/busy data would use only about 5MB of storage. Even publishing 36 months of free/busy data wouldn't overtax storage space.
After you decide on a standardized publication interval for your Exchange enterprise, you can use AD Group Policy Objects (GPOs) to apply it. When you change the setting, keep three items in mind. First, although "XCLN: How to Configure Default Free/Busy Options" specifies that the maximum number of months is 12, the upper limit is 36 for Outlook XP and later. Second, your maximum publication interval will be governed by your oldest client. Third, don't forget to translate the months into hex form.
Troubleshooting Problems with the Free/Busy Map
The problems I've encountered with the free/busy map mainly relate to the amount of free/busy data published. As I just described, different settings in clients can result in different amounts of data being published. To troubleshoot this problem, you need a way to determine who is publishing fewer months than expected.
Using Mdbview, you can open the public folder store and view the raw properties of a mailbox's free/busy data. As Figure 4 shows, PR_LAST_MODIFIER_NAME is one of these properties. (In older Mdbview versions, the property's name might be 0x3FFA. The version I used at the time of writing this article was 6.5. You can obtain the latest Mdbview version from the Microsoft Download Center at http://www.microsoft.com/downloads. Search using the keyword mdbvu32.) This property holds the name of the account that last generated the free/busy data. After you know who generated the data, you can use Mdbview to access that person's LocalFreebusy message, assuming you have adequate rights to access the mailbox. By examining the 0x6869 property, you can determine whether the person is publishing fewer months than expected. If so, you can then help the person update his or her Outlook client to publish more months of data.
Another common problem is a lack of free/busy data for a particular administrative group or site. When a client needs to access free/busy data, it first checks the local server's public folder store for the data. If unsuccessful, the client tries a server in its routing group, then expands to servers in other routing groups until it finds a public folder store with a copy of the data.
In cases in which an administrative group's free/busy folder has been replicated, the free/busy message might not have been replicated to the public folder stores that are being checked by the client. With the OWA versions in Exchange 2003 and Exchange 2000, you can use Web queries to check servers' public folder stores for free/busy maps. You can query each server in which replicas should be found to see which one doesn't have the free/busy map.
Here's how Web queries work: From Microsoft Internet Explorer (IE), you use a URL to query a specific public server's public folder store for a free/busy map. For example, the URL http://SRV3/public/?cmd=freebusy&start=2007-02-14T00:00:00-05:00&end=2007-02-14T23:59:00-05:00&interval=30&u=SMTP:emma@neulan.net queries the public store on the SRV3 server. The cmd= parameter specifies that you want to check for free/busy data. The u=SMTP: parameter specifies the account to check. The start=, end=, and interval= parameters define the range of free/busy information to return. The Microsoft article "XCCC: Description of the Command to Retrieve Free/Busy Information From a Calendar Public Folder" (http://support.microsoft.com/?kbid=813268) describes exactly how to format queries.
The Web query produces an XML data page that contains a series of tags. You need to look for the <a:fbdata> tag. If a free/busy map is present, the tag might look something like <a:fbdata>000000000000000000000000111333333000000000000000</a:fbdata>. If a free/busy map isn't present, the <a:fbdata> tag will contain all 4s.
Effectively Support Your Users or Customers
You rarely find anyone in the business world whose days and plans aren't affected in some way by the necessity of meeting with other people. Scheduling free/busy information is a crucial component for effective use of Exchange calendars. By understanding where and how free/busy map information is stored and generated, you'll be much better equipped to support your users or customers.
End of Article
Prev. page
1
2
[3]
next page -->
