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

shodaner

Green Team
04.02.2022
102
9
BIT
102
Добрый

Столкнулись с тем, что у некоторых пользователей при создании нового события в календаре в планировщике не отображаются уже существующие записи. Просто серая полоса на все даты. У других людей при добавление этого человека в событие - также он серый. Может кто знает, как это лечится.
Пример:
Снимок.PNG
 
ВРОДЕ бы, надо busytime.nsf пересоздать. Но не уверен.
 
ВРОДЕ бы, надо busytime.nsf пересоздать
Проверил, у этого человека в локальном каталоге вообще нет ни busytime.nsf ни busytime.ntf . Однако у меня самого в каталоге busytime.nsf нет, есть только busytime.ntf. Т.е. тоже не создан из темплэёта. И при этом мой планировщик не глючный.
 
На сервере, я имел в виду. Туда агрегируются данные из всех календарей.
 
А на каком конкретно сервере искать то? Проверил на серверах с почтовыми базами там только busytime.ntf. Посмотрел на административных серверах - там тоже только busytime.ntf. Сама база нигде не создана. И как её создать если она нужна для планировщика?
 
А на каком конкретно сервере искать то? Проверил на серверах с почтовыми базами там только busytime.ntf. Посмотрел на административных серверах - там тоже только busytime.ntf. Сама база нигде не создана. И как её создать если она нужна для планировщика?
Она при открытии из клиента не отображается в списке баз. Вы физически среди файлов ее найдёте. В корне data на сервере. Открыть из клиента можно руками через CTRL-O, явно указав имя файла - busytime.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
Следуя инструкции процесс пересоздал на кластере эту базу, постепенно запихнул в неё доки, но с этим человеком ничего не изменилось. Что ещё может быть? Возможно, что-то не читаемо в его базе почтовой? Или неверная настройка на уровне локальной программы?
Снимок4.PNG
 
Administration Server правильный указан? Права в ACL у сервер(а/ов) нормальные? Сравните с каким-нибудь "хорошим" пользователем в этом же кластере.
UPD. Пользователь не переименовывался?
 
Последнее редактирование:
У меня ещё на 6-ке была такая проблема. База busytime или clubusy тут ни при чём, пересоздавать бесполезно.
В своей старой базе знаний статьи не нашёл, но в памяти вертится, что это скорее всего настройки ACL почтовой базы - я когда-то ограничил доступ, удалив оттуда всех, кроме себя, в т.ч. и сервера. Потому, скорее всего, сервер и не может отстроить расписание на этого пользователя. т.к. не имеет доступа к его почте.
И ещё бы Owner'а проверил в почтовой базе.
 
  • Нравится
Реакции: shodaner
Да вы оказались совершенно правы, были ограничены доступы к просмотру. Но за все советы спасибо - пригодятся не раз ещё
Снимок5.PNG
 
  • Нравится
Реакции: Мыш
OFF. Был у нас очень безопасный пользователь, он в своем п/я любил к письмам доступ ограничивать. Только вот бэкап почты делался с реплики на другом сервере , куда эти письма, ессно, не попадали. И однажды основной сервер покрылся... :-/
 
Команда для диагностики расписания ящика наверняка бы помогла выявить проблему с доступом к нему
tell sched show "CN=USERNAME//OU=orgunit/O=Organization"
 
  • Нравится
Реакции: Мыш
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!