Subject: Re: Some Ideas
Thanks for the response, see my comments below.
For the users having the problem (Alice), when she adds
another users calendar (Bob) to her own, it does not show any details.
Its hard to tell if this is a federated calendar issue or a busytime
issue so lets try to determine that first. There are a couple ways
to see if its busytime so lets try the quickest first.
Have Alice invite Bob to a meeting and then try to see his details
in the scheduling grid on the “Find Available Times” tab. Just right
mouse click on any of Bobs meetings in the grid and select the
“Details of entry for…” choice.
If she gets the dialog:
then we need to focus on the busytime system (and Bobs Calendar Profile).
I tried this - and all of the info was there as expected (ie: Subject, Chair
and Location), so that is looking good (and pointing to a federated calendar
issue). We have never had to delve into this, so I don’t know much about the
internal mechanics. I have also run through the following steps (comments
below), but don’t think that is the issue.
If she sees a dialog with the Chair, Location and other info then we
need to focus on the Federated Calendar side of things.
We have tried changing the options, saving, replicating, and
changing back, but the problem persists.
I have also tried setting up policies to enforce these
settings, removed them etc.
I know we fixed at least one policy related bug in 8.52 where
settings were not being twiddled properly to match the policy so it
could be you are hitting that problem.
Not sure where else to look. My thought is it would be good to
start by trying to reset the cache on the server (if possible). I
have also confirmed that the “Schedule Manager” is running.
It kind of sounds like its an issue w/the settings on Bobs Calendar
Profile so Ill focus on looking there for now. The setting on his
profile is just copied by Schedule Manager to his busytime record
and then it is used to filter incoming lookups. So grab your copy of
NotesPeek (or equivalent tool of your choice) and lets go check out
busytime and Bobs Calendar Profile…
First off, open the busytime dB (busytime.nsf or clubusy) with your
Notes client and find Bobs busytime record. It should be easy as
there should only be 1 record for Bob. If you have more than one
then that is a totally different issue to deal with (so start a new
thread). You want to look for 2 items: AllowList and AllowBusyDetailsAccess
Just one record.
AllowList is who is allowed to see Bobs busytime. A “” means
“Everyone”. Otherwise its a list of names of who can see Bobs busytime.
AllowBusyDetailsAccess is who is allowed to see Bobs details. A “”
means “Everyone”. No AllowBusyDetailsAccess item means Bob has a
pre-R6 Calendar Profile and so no means to control the setting so
details will not be harvested (so no DetailsList item on his record
to possibly return data to Alice). Otherwise its a list of names of
who can see details about entries.
Both AllowList and AllowBusyDetailsAccess had a single NULL value (ie: length
of 1, and a displayed value of “\0”) when viewed in NotesPeek. Which may be a
bit odd given the values below.
Now use NotesPeek to open Bobs mail file and find his Calendar
Profile doc. You will want to check the setting that is actually
stored on his Home Server’s replica and not a local replica (since
Sched only reads what is on the Home Server replica). You want to
look for the AllowBusyAccess item.
Whatever value you have set there is copied over to the busytime
record so the values here should match what you found before. If
not, Sched missed the update somehow. I think it should autocorrect
this on task restart so if there is a difference here then
restarting Sched should fix it.
This had a string of length 0, with an empty string when viewed in NotesPeek.
Which was different, however looking at a user that is working fine, these
value were identical (ie: empty in the calendar profile, and NULL in the Local
free time info DB).
Next take a gander at the BusyTimeHarvestOptOut item on Bobs
Profile. Make sure it is NOT “1” which indicates Bob is not allowing
detail harvesting even though you said it was enabled earlier. If
the item is missing then that would be equivalent to “1” since it
should be there on all R6+ Calendar Profile docs; only pre-R6 users
lack it and thus the feature should be auto-disabled for them for
privacy reasons obviously.
This had a value of “0” (for both Bob, and the “reference” user who is working
OK).
Now that you know how the items to look for and how they are used,
you can get an idea of where the problem lies.
If the items you find on the profile do not match the settings you
pushed by a policy or that show in the UI when Bob changes them then
the answer is to resave them and check to make sure they reset
properly. (If they don’t then open a ticket with Support so we can
spend more time on this with you to see why not.)
If the items on the profile match what you expect but they do not
match their peers on the busytime record then you need to simply
resave the profile doc and Sched will pick up the changes and put
them into busytime. If it does not, we should see why not by turning
on an INI and watching what Sched does. You should probably open a
support ticket for this case too.)
Whew, that should help you get started and keep you busy for half an
hour at least…
Thanks very much for the info, and the detailed steps. Any other thoughts
around the federated calendar (a quick search in the help came up with very little)?
Cheers.
