Разметка календаря сервера macOS - возможно, обратные проблемы с DNS?

Я нахожусь в процессе миграции дюжины учетных записей пользователей с одного старого сервера под управлением Mac OS X 10.10.5 Yosemite и Server 5.015 - компьютер называется server-2015.example.com

Новый сервер работает под управлением macOS 10.13.4 High Sierra и Serve 5.6 - машина называется server-2018.example.com

Вместо того, чтобы выполнять автоматическую миграцию, я перемещаю вещи вручную, чтобы гарантировать, что настройки-трюки не тянутся.

Передача календаря Server-2018 доставляет мне неприятности. Кажется, что делегирование ресурсов работает (например, user1 и users2 являются членами группы, которая является делегатом ресурса конференц-зала), но пользователи не могут надежно делегировать друг друга, как это возможно при использовании Server-2015. Попытки добавить делегата с помощью Calendar.app (Preferences ->. Accounts -> Delgation -> Edit) иногда бывают успешными, но иногда приводят к ошибке «no such person» или даже «этот сервер не поддерживает делегирование».

(Обновление - ошибка «нет такого человека», по-видимому, является результатом того, что некоторым учетным записям пользователей не присвоен адрес электронной почты - когда им присваивается адрес электронной почты, Calendar.app с радостью предоставит им статус делегата.)

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

Я видел некоторые комментарии, что система календаря чувствительна к конфликтам имен хостов и обратных DNS.

Единственное, что может быть проблемой, которую я не смог отследить, это то, что обратный DNS для сервера не соответствует ожиданиям. Возможно, совершенно не связанный, сервер, кажется, держит старое имя хоста.

Сервер-2018 предоставляет DNS для локальной сети, в том числе и для себя. IP-адрес сервера - 192.168.133.253, и в DNS есть запись A для server-2018.example.com, которая указывает на это. Server.app имеет имя хоста 2018.example.com, а обратная зона имеет запись PTR для 192.168.133.253, для которой установлено значение server-2018.example.com. Однако, когда я делаю «nslookup 192.168.133.253» или «dig -x 192.168.133.253», я получаю старое имя хоста для сервера, а именно server-2018-e.example.com (в какой-то момент у меня были имена хостов, чтобы различать ethernet и интерфейсы аэропорт / WiFi - таким образом, 2018-е и 2018-названия).

Я удалил имя хоста server-2018-e из любого места, где я могу его найти: DNS-записи сервера, нет записей PTR, A, MX или CNAME для server-2018-e.

«Имя хоста», указанное в Server.app -> Обзор - server-2018.example.com

«Имя компьютера», указанное в Server.app и в «Системных настройках» -> «Общий доступ», является server-2018-example-com

Я очистил кэш DNS в системах, которые я использую для поиска с помощью команды "sudo killall -HUP mDNSResponder"

Я не могу найти, откуда взялся этот долбанный сервер2018-e.example.com? Есть ли какое-то глубоко скрытое место, где программное обеспечение Server.app сохраняет старое имя хоста?

Я выключил и перезапустил DNS-сервер на сервере-2018, а также включил и отключил питание оборудования.

Все "scutil --get HostName" и "scutil --get LocalHostName" и "scutil --get ComputerName" дают ожидаемые результаты, без "2018-e" в них.