Estou no processo de migrar uma dúzia de contas de usuário de um servidor antigo que executa o Mac OS X 10.10.5 Yosemite e o Servidor 5.015 - a máquina é denominada server-2015.example.com
O novo servidor está executando o macOS 10.13.4 High Sierra e o Servir 5.6 - a máquina é nomeada server-2018.example.com
Em vez de fazer uma migração automática, estou movendo as coisas manualmente para garantir que as configurações não sejam arrastadas.
A delegação do calendário do Servidor-2018 está causando problemas. A delegação de recursos parece funcionar (user1 e users2 são membros do grupo que é um delegado do recurso da sala de conferência, por exemplo), mas os usuários não podem delegar um ao outro com segurança, como é possível usar o Server-2015. As tentativas de adicionar um delegado usando Calendar.app (Preferences - & gt ;. Accounts - > Delgation - > Edit) às vezes são bem-sucedidas, mas às vezes resultam em um erro "no such person" ou até "este servidor não suporta delegação "erro.
(Atualização - o erro "nenhuma dessas pessoas" parece ter sido o resultado de algumas contas de usuários não terem um endereço de e-mail atribuído - quando elas recebem um endereço de e-mail, o Calendar.app concede a elas o status de delegado.) / p>
No começo eu pensei que isso fosse um problema do OpenDirectory - o antigo servidor estava usando o OpenDirectory para contas de usuários e grupos, mas eu não liguei para o novo servidor pensando que eu não precisava de nenhuma das coisas que ele fornecia. Uma vez que algumas das vezes a delegação parece funcionar, isso não parece ser uma questão - está correto?
Eu tenho visto alguns comentários de que o sistema de calendário é sensível ao nome do host / conflitos DNS reversos.
A única coisa que pode ser um problema que não consegui rastrear é que o DNS reverso do servidor não parece ser o que eu esperava. Talvez totalmente não relacionado, o servidor parece estar segurando um antigo nome de host.
O Servidor-2018 está fornecendo DNS para a rede local, incluindo para si mesmo. O endereço IP do servidor é 192.168.133.253 e o DNS tem um registro A para server-2018.example.com que aponta para isso. O Server.app tem um nome de host 2018.example.com e a zona inversa tem um registro PTR para 192.168.133.253 definido como server-2018.example.com. No entanto, quando eu faço "nslookup 192.168.133.253" ou "dig -x 192.168.133.253" eu recebo um nome de host antigo para o servidor, ou seja, server-2018-e.example.com (em um ponto eu tinha nomes de host para distinguir o ethernet e interfaces aeroporto / WiFi - assim, os nomes 2018-e e 2018).
Eu removi o nome do host server-2018-e de todos os lugares que eu posso encontrar: os registros DNS do servidor, não há registros PTR, A, MX ou CNAME para server-2018-e.
O "Hostname" listado em Server.app - > A visão geral é server-2018.example.com
O "Nome do Computador" listado em Server.app e em "Preferências do Sistema" - > "Compartilhamento" é server-2018-example-com
Eu limpei o cache do DNS nos sistemas que estou usando para fazer as pesquisas usando "sudo killall -HUP mDNSResponder"
Eu não consigo encontrar de onde vem o server-1818-e.example.com? Existe algum lugar oculto profundo onde o software Server.app está mantendo o nome do host antigo?
Eu desliguei e reiniciei o servidor DNS no servidor-2018, assim como liguei o hardware.
Todos os "scutil --get HostName" e "scutil --get LocalHostName" e "scutil --get ComputerName" fornecem os resultados expeceted, sem "2018-e".