Я потратил большую часть этого утра на борьбу с этим, поэтому я поделюсь им на случай, если другие в моей ситуации столкнутся с той же проблемой.
В настоящее время мы находимся в период сосуществования Exchange 2003 / Exchange 2010. На нашем сервере Exchange 2010 есть несколько тестовых почтовых ящиков, остальные находятся на Exchange 2003, а наш сервер создания автономной адресной книги в настоящее время является сервером Exchange 2003.
Вчера кто-то ушел из компании, поэтому мы следовали нашей обычной процедуре и скрыли их из всех списков адресов Exchange и всю ночь ждали, пока будет восстановлена автономная адресная книга. Когда я вошел сегодня, виновный пользователь все еще числился в нашей автономной адресной книге. Для справки: этот почтовый ящик пользователя находится на сервере Exchange 2003.
Я проверил журналы событий на сервере Exchange 2003, и никаких предупреждений или ошибок не было зарегистрировано в ранние часы службой системного помощника Microsoft Exchange во время процесса создания автономной адресной книги. Подумав, что это просто случайность, я вручную перестроил автономную адресную книгу с теми же результатами (без предупреждений / ошибок и пользователь все еще находится в автономной адресной книге).
В Outlook нет ошибок синхронизации, и я проверил (с помощью диспетчера Exchange System Manager на сервере Exchange 2003), что автономная адресная книга существует и все еще создается рано утром, а также когда я вручную перестраивал ее. этим утром.
Для исследования этой проблемы мне потребовалось использовать немного ноу-хау Active Directory, а также немного Exchange-2010-Management-Shell-fu.
Первое, что я проверил, - правильно ли реплицируются два моих контроллера домена. Моя первоначальная мысль была, когда я обновил Скрыть из списков адресов Exchange в разделе «Пользователи и компьютеры Active Directory», который я изменил на одном контроллере домена, который не реплицировался на другой контроллер домена, выбранный процессом создания автономной адресной книги. Как оказалось, контроллеры домена являются репликация выполняется правильно, и проблема не в этом.
Следующее, что нужно сделать, - это проверить некоторые атрибуты Active Directory и их текущие значения. Мой предпочтительный инструмент для работы на низком уровне с Active Directory - ADExplorer от Sysinternals, однако ADSI Edit будет делать такую же хорошую работу, если вы этого предпочитаете.
Первый атрибут, на который я обратил внимание пользователя, - это msExchHideFromAddressLists атрибут. Это должно быть ЛОЖНЫЙ если пользователь должен появиться в списках адресов и ПРАВДА если они не должны. На самом деле это просто проверка здравого смысла, поскольку именно это обновляет Active Directory Users and Computers, когда вы (снимаете) отметку Скрыть из списков адресов Exchange флажок. Это было правильно показано ПРАВДА.
Следующим атрибутом для проверки является showInAddressBook. Это многозначный атрибут, который содержит все списки адресов, в которых должен отображаться этот пользователь. Обычно он должен содержать хотя бы один список адресов, в котором должен отображаться пользователь, но для всех, у кого есть msExchHideFromAddressLists атрибут установлен на ПРАВДА этот атрибут вообще не следует устанавливать. Это была самая большая подсказка, поскольку у этого пользователя все еще были значения в этом атрибуте, которые следовало удалить, когда Скрыть из списков адресов Exchange флажок установлен.
Служба обновления получателей на сервере Exchange 2003 отвечает за обновление значения showInAddressBook атрибут (среди прочего) в Active Directory, поэтому я определил, что по какой-то причине здесь не работает служба обновления получателей.
Когда я изначально установил Exchange 2010, мне пришлось запустить setup.com /PrepareLegacyExchangePermissions чтобы предоставить службе обновления получателей некоторые необходимые ей разрешения, потому что Exchange 2010 немного перемещает вещи.
Чтобы проверить разрешения, я открыл Active Directory Users and Computers и выбрал Просмотр => Расширенные функции чтобы я мог просматривать атрибуты безопасности для учетной записи пользователя в Active Directory. Затем я открыл нарушившего пользователя, проверил вкладку безопасности и сравнил его с другим пользователем, который должен быть включен в автономную адресную книгу. Хотя я не проверял каждое разрешение, сразу было очевидно, что пользователь, который должен быть в автономной адресной книге, имел много предоставлено больше разрешений, чем у только что вышедшего пользователя. Проверяя нескольких других пользователей, они также получили гораздо больше разрешений, чем пользователь-нарушитель.
Что-то, что я случайно заметил, - это то, что нарушивший пользователь права не наследовал разрешения от родительских объектов, в то время как все другие проверенные мной пользователи были. Я знаю по опыту, что это обычно происходит только тогда, когда пользователь является (или когда-то был) членом Привилегированная группа Active Directory. Убедившись, что они больше не являются членами привилегированной группы, я вернулся в ADExplorer и изменил adminCount атрибут этого пользователя 0 с 1. Затем я вернулся в Active Directory - пользователи и компьютеры и разрешил этому профилю пользователя наследовать разрешения от родительских объектов.
После этого я вошел в свойства пользователя и снял флажок Скрыть из списков адресов Exchange флажок, а затем снова установите его. Я подождал несколько минут, пока служба обновления получателей сделает свое дело, и, конечно же, через 5 минут, когда я посмотрел на объект пользователя в ADExplorer, служба обновления получателей удалила showInAddressBook атрибуты, на выполнение которых ранее не было разрешения. Быстрая перестройка автономной адресной книги вручную, и все будут довольны.