Hi At once (what to tell difficultly) free/busy Information it has ceased to be displayed truly for a part of users. I.e. I (as well as any user of a server or the domain in general)should make an an appointment with this users and i see him free/busy information in three variants 1) or full and true free/busy information 2) or i see part and not true free/busy information 3) or i see "grey line" without tooltip "no information" I read this article and do it http://technet.microsoft.com/en-us/library/bb124868(EXCHG.65).aspx Has no result. Combinations of different schedules MadFB of result have not allowed (from "not to start never" to to work 24 hours). The situation is corrected for these "cripples" of free/busy information only by start Outlook with key "/cleanfreebusy" for some time (from an hour about one days), but allcome back after a some times. We have One domain in one forest. 4 sites with 4 Exchange 2003 servers. All users use Outlook 2003 Thanks for help. Oleg

I'd check that you are replicating the Schedule+ Free/Busy system folder between all the servers and that public folder replication is working correctly. The only other thing I can think of is to check to ensure that you are fully updated regarding patches for Outlook 2003.

Issue description: A part of users Free/Busy [FB] info may out of time or unavailable Explanation: For FB replicas on different server, assuming that replication interval is 15 mins, FB data will be 15 mins out-of-sync between servers. But client has 45 mins publish interval. So, out-of-sync can be up to 1 hour for calendar. For the FB data only located on one server, the out-of-sync will only be max 45 mins Check info: 1. Do exchange servers all belong to one administrative group [AG] among four sites, or each site has one AG? 2. If therere multiple FB public folder replicas exist [Check in ESM], check if the issue persisted when users access a specific replica store. Is the problematic users all located on one mailbox database or one mailbox server? 3. Please try to reproduce issue via OWA 4. Please also check the Microsoft Exchange System Attendant service on all public folder servers Notes: System Attendant has MadFB agent which publishes new FB message and deletes the old or duplicated References: The info in this article is helpful when we troubleshoot the FB Maintaining and Repairing Free/Busy Data

My info: We've got one administrative group [AG] Problematic users located on one server and on the different mailbox stores When i try to do appointment with these problematic users via OWA, i see same problem Microsoft Exchange System Attendant work on all servers AdditionalWe've got this event in application logEvent Type:ErrorEvent Source:MSExchangeIS Public StoreEvent Category:Replication Errors Event ID:3093Date:12.12.2008Time:17:29:49User:N/AComputer:SERVERDescription:Error -2147221233 reading property 0x67010003 on object type tbtOwningFolders from database "SERVER Storage Group 1\Public Folder Store (SERVER)".

By default, each FB server only holds that sites FB data, you must replicate FB folders to replicate among multiple sites for all users, right? If the issue only persists on one exchange server, the possible cause is, the replica of FB folder goes wrong on that servers public store due to public folder replication issue, problematic users default public store is the local public store on that server, right? Which server do you find this error event 3093? On the server those problematic users stay, or the server which contains other users FB data that cant be showed to the problematic users Which database actually shows in the error 3093? Is he database that contains the FB data problematic users cant see at other sites, or the database that contains the replica of FB data at the server in problematic users site? Please compare the replica of FB folder on the problematic server with the replica on other servers Please check if SiteFolderServer attribute points to the right public store on the problematic users server [Procedure] I suggest that raise up the diagnose logging level for replication incoming and outcoming [Procedure], and check the replication event