다음을 통해 공유

Exchange 2007 - Legacy Free/Busy Info not Publishing to Public Folders

  • 아티클

 

Problem:
=====================================

Free/Busy information was not being published to Public Folders for room/resource mailboxes.

This was causing the Free/Busy information for the rooms, as seen by Outlook 2003 clients, to not be accurate, causing users to send meeting requests for times they though the room was free, and  would then be returned denied because the room was actually already booked. The issue was affecting only one mailbox server. Outlook 2007 or higher clients, or users accessing via OWA saw correct Free/Busy information.

Summary of Events:
======================================

When I saw the problem, I began troubleshooting the process by which "Legacy" Free/Busy is published from a mailbox when a meeting is scheduled by a non-Outlook client. This process applies to meetings scheduled through the AutoAccept functionality of Room mailboxes, as well as meetings scheduled through OWA by regular users. This Legacy Free/Busy information is only used by Outlook 2003 or earlier clients, or for mailboxes on Exchange 2003 (or earlier). This is why the problem was limited to Outlook 2003 clients viewing the information.

The process by which the Legacy F/B is published breaks down as follows:
- Meeting is scheduled in the mailbox by non-Outlook client (OWA or AutoAccept)
- F/B information is then sent to the System Attendant (SA) mailbox
- The F/B publishing process (MSExchangeFBPublish) that runs in the System Attendant regularly checks the SA for new F/B messages on a regular basis (roughly 5 minutes) and then publishes the information to the F/B public folders

Most of the time, it is the actual publishing process that breaks, and the F/B messages are found sitting in the SA mailbox.

So, the first thing I starting looking at was if we had messages sitting in the SA mailbox. We did not. So the troubleshooting concentrated there with the question, "why aren't the messages getting to the SA mailbox?"

Because there is very little tracing or logging around the process of the F/B message being sent to the SA mailbox, and how it is sent is not well documented, we needed to get debug tracing analyzed to see where the process was breaking down.

Once the tracing was captured, it was analyzed here, and it was found that when the meeting was being scheduled in the room mailbox, the F/B message was indeed being submitted for the SA mailbox. One piece of information that was revealed in looking at the code responsible for this, was that we do indeed use standard message transport to deliver the message. The message is sent to transport, initially with the LegacyExchangeDN value of the SA mailbox, which is then resolved by transport for delivery. This is done by the Hub Transport server(s).

Once this was known, we now knew to look in transport for what happened to the message. When we went to use the Message Tracking center to track messages bound for the SA mailbox, putting the LegacyExchangeDN value for it in the Recipient box and clicking "Resolve Recipient" caused the box to blank out. What normally occurs is that the recipient box is filled in with the SMTP address of the System Attendant.

We then used ADSIEdit to check the properties of the System Attendant for the problem server, and found that the proxyAddresses attribute on the System Attendant was blank.

We then used ADSIEdit to populate this attribute with a valid SMTP address. Once we did this, we found that the System Attendant mailbox was receiving messages and we also saw that the Free/Busy information started appearing for some of the test meetings we had previously created.

Then then scheduled a meeting for a large batch of the rooms, and after 5-10 minutes they were all displaying the Free/Busy information for the meeting created.

Findings / Root Cause:
==========================

The problem here was that the System Attendant was missing values for the proxyAddresses attribute, thus the Free/Busy messages could not be delivered to it.

This would not have just "happened"; there must have been something done with this server at a previous time that caused the addresses to be cleared from the System Attendant object. When Exchange is installed, the default SMTP address is set in the proxyAddresses attribute as SMTP:SERVERNAME-SA@domain.com , where SERVERNAME is the server name and domain.com is the default SMTP domain.

Also, the DisplayName of the System Attendant mailbox is normally "Microsoft System Attendant". For this server, it was "System Attendant". This provides additional suspicion that something previously occurred with the System Attendant mailbox and when it was "fixed", it was not properly fixed, and we ended up with missing proxyAddresses.

More Information:
============================

In some additional research I did after knowing what our root cause was, I went back to see if there was something that would have alerted us to the issue sooner, and found that indeed there was. We could have looked at the output of an Exchange Best Practices Analyzer report run against the server, and it would have alerted to the System Attendant missing the proxyAddresses attribute values.

However, prior to the further research regarding the publishing process, we likely would not have immediately made the connection between the missing value and the F/B publishing failure. So, we would have followed up on the ExBPA output and fixed the SA proxyAddresses attribute, and then found out that ended up fixing our problem.