BusyTime reporting users as "Unavailable"

HCL Domino Domino Forum
1

Having an issue with busytime.nsf, or rather clubusy.nsf. Multiple users are being incorrectly reported in busytime as “Unavailable”. They are being flagged as unavailable for significant periods of time, say 90% of a given week. It is very difficult to establish a pattern of those periods where they are flagged unavailable but there is variation across the users affected.

The network comprises multiple Domino servers. Key to the topology is a clustered mail server.

After scouring the forums and help we have tried a few things to rectify the situation. They are:

  1. In a number of affected user’s calendars we have checked their availability settings. Those checked were ok.

  2. For a number of affected users, we checked the meetings view in their calendar’s for any discrepancies in repeat meetings, or for Replication Save Conflicts? Nothing unusual noted.

  3. Deleted some of the affected users from clubusy.nsf. To no avail.

  4. Initiated a rebuild of Clubusy on the clustered servers, by:

a. Shutting down Sched and Calconn tasks (tell sched q, tell calconn q, then issued dbcache flush a couple of times)

b. In the \Data directory of both cluster servers, the Clubusy.nsf was renamed (clubusy.old) and moved.

c. On both cluster servers the Sched and CalConn tasks were restarted.

We are struggling with where to next! Any direction would be gratefully received.

Thanks

Wayne Granger

2

Subject: BusyTime reporting users as “Unavailable”

HiLooks like you have missed out on steps documented in this Technote #1141060:

“How to resolve Free Time inaccuracies in Notes/Domino Calendaring and Scheduling”

Besides that you may want to check the Meetings View for any Repeat entries - Reminders, Meetings, Appointments that go too far into the future e.g 2050

Thanks.

Robert Mendonca

3

Subject: RE: BusyTime reporting users as “Unavailable”

Robert, do appreciate your input. We determined that across a Notes Network of some 300 users that the problem impacted approximately 50% of users. The basis of our approach to resolving the issue was the technote to which you directed us. I may not of articulated that as clearly as I should have in my initial post. To resolve the situation we have had to get users to go into their preferences and make a minor modification to their availablity. Presto! A little inconvenient, but workable. The users can then go back and return their availability to its previous setting.

For those who may reference this post, in the lead up to the issue, the only changes in our LDN configuration was the application of a couple of “patches” from IBM to address changes to the DST period in our locale (South Australia). Lets blame the poiliticians!

Thanks again Robert.