Проблема с планировщиком календаря

[shodaner]

Добрый

Столкнулись с тем, что у некоторых пользователей при создании нового события в календаре в планировщике не отображаются уже существующие записи. Просто серая полоса на все даты. У других людей при добавление этого человека в событие - также он серый. Может кто знает, как это лечится.
Пример:

 

[Мыш]

ВРОДЕ бы, надо busytime.nsf пересоздать. Но не уверен.

 

[shodaner]

ВРОДЕ бы, надо busytime.nsf пересоздать

Проверил, у этого человека в локальном каталоге вообще нет ни busytime.nsf ни busytime.ntf . Однако у меня самого в каталоге busytime.nsf нет, есть только busytime.ntf. Т.е. тоже не создан из темплэёта. И при этом мой планировщик не глючный.

 

[Мыш]

На сервере, я имел в виду. Туда агрегируются данные из всех календарей.

 

[shodaner]

На сервере

А на каком конкретно сервере искать то? Проверил на серверах с почтовыми базами там только busytime.ntf. Посмотрел на административных серверах - там тоже только busytime.ntf. Сама база нигде не создана. И как её создать если она нужна для планировщика?

 

[Мыш]

А на каком конкретно сервере искать то? Проверил на серверах с почтовыми базами там только busytime.ntf. Посмотрел на административных серверах - там тоже только busytime.ntf. Сама база нигде не создана. И как её создать если она нужна для планировщика?

Она при открытии из клиента не отображается в списке баз. Вы физически среди файлов ее найдёте. В корне data на сервере. Открыть из клиента можно руками через CTRL-O, явно указав имя файла - busytime.nsf

 

[shodaner]

Вы физически среди файлов ее найдёте.

Не нашёл, вот кусок списка с двух серверов = одного административного, одного почтового. Только ntf

 

[Мыш]

Аааа, у Вас кластеры? Тогда clubusy.nsf.

 

[shodaner]

Тогда clubusy.nsf.

Действительно нашёл, действительно там списки людей и ресурсов. Однако не вижу ntf для этой базы, только nsf. Если я её грохну и рестартану сервер - она пересоздастся?

 

[Мыш]

How to recreate clubusy.nsf:
Clubusy.nsf is the free time database on a clustered server. To recreate or restore it, do the following:

NOTE: This process must be done to ALL SERVERS in the cluster to avoid replication. To send the same command to multiple servers at once, you may refer to the product documentation below and follow Step # 7.

Ссылка скрыта от гостей

1. If possible, map a drive or FTP to the Domino server's Data directory.
2. In Domino Administrator, open the live console.
3. Shut down the Sched and Calconn tasks on all clusters and flush the database cache with the following commands:
tell sched q
tell calconn q
tell RnRMgr q
dbcache flush
NOTE: Several "dbcache flush" commands may be required depending on the operating system and server load.

4. On the Domino server's Data directory, find clubusy.nsf and delete it. Clubusy.nsf contains no historical data so there is no reason to keep it when rebuilding.
NOTES:
Steps 3 and 4 must be done on ALL clustermates before Step 5 is performed on any server. Otherwise, old data may be added back into the clubusy database and invalidate what you are trying to do. If you do not do this correctly, you must restart the process for clubusy.nsf over again.

5. Issue the following commands on all clustermates (not case sensitive):
load sched
load CalConn
load RnRMgr

 

[shodaner]

Следуя инструкции процесс пересоздал на кластере эту базу, постепенно запихнул в неё доки, но с этим человеком ничего не изменилось. Что ещё может быть? Возможно, что-то не читаемо в его базе почтовой? Или неверная настройка на уровне локальной программы?

 

[Мыш]

Administration Server правильный указан? Права в ACL у сервер(а/ов) нормальные? Сравните с каким-нибудь "хорошим" пользователем в этом же кластере.
UPD. Пользователь не переименовывался?

 

[VladSh]

У меня ещё на 6-ке была такая проблема. База busytime или clubusy тут ни при чём, пересоздавать бесполезно.
В своей старой базе знаний статьи не нашёл, но в памяти вертится, что это скорее всего настройки ACL почтовой базы - я когда-то ограничил доступ, удалив оттуда всех, кроме себя, в т.ч. и сервера. Потому, скорее всего, сервер и не может отстроить расписание на этого пользователя. т.к. не имеет доступа к его почте.
И ещё бы Owner'а проверил в почтовой базе.

 

[Мыш]

Хороший мануал

 

[shodaner]

Да вы оказались совершенно правы, были ограничены доступы к просмотру. Но за все советы спасибо - пригодятся не раз ещё

 

[Мыш]

OFF. Был у нас очень безопасный пользователь, он в своем п/я любил к письмам доступ ограничивать. Только вот бэкап почты делался с реплики на другом сервере , куда эти письма, ессно, не попадали. И однажды основной сервер покрылся... :-/

 

[Wanderstep]

Команда для диагностики расписания ящика наверняка бы помогла выявить проблему с доступом к нему
tell sched show "CN=USERNAME//OU=orgunit/O=Organization"