Назад | Перейти на главную страницу

Exchange 2003: почтовые ящики и записи адресной книги не создаются

Во-первых, мы не часто меняем персонал или учетные записи там, где я работаю, поэтому эта проблема могла возникнуть в любой момент в течение последних 3-4 месяцев.

Мы запускаем домен AD с использованием Server 2003R2 и Exchange 2003. Сервер Exchange также является DC и GC-сервером.

Вчера я создал 3 новых аккаунта AD с почтовыми ящиками. По крайней мере, я так думал. Когда я попытался отправить тестовые сообщения этим учетным записям, я обнаружил, что почтовые ящики вообще не были созданы.

Используя ADSIedit для сравнения одной из новых учетных записей с существующей, я обнаружил, что параметр msExchUserAccountControl был "". Установка этого значения на 0, как и существующая учетная запись, привела к созданию соответствующего почтового ящика. Единственные другие настройки, которые я мог видеть, которые не были установлены в новых учетных записях, но были установлены в существующей, относились к адресным книгам. Я ожидал, что они будут обновляться автоматически. Однако глобальный список адресов также не обновляется, и попытка ввести эти настройки адресной книги напрямую с помощью ADSIedit привела к появлению сообщения «Пользователь не найден».

Возможно, случайно, хотя я подозреваю, что нет, но начиная со вчерашнего дня использование Центра отслеживания сообщений на моей рабочей станции XP теперь заканчивается ошибкой «Доступ запрещен», ID 80070005. В журналах событий на рабочей станции или сервере нет ничего, что могло бы пролить свет на это . Центр отслеживания сообщений на сервере отлично работает с той же учетной записью пользователя. Все это заставляет меня подозревать, что что-то, связанное с безопасностью, нарушено, но что?

Гугла оказалось очень мало. Единственные записи, которые мне удалось найти с похожими описаниями, все относились к перемещению почтовых ящиков между версиями. Мы никогда не перемещали почтовый ящик, и это фактически первый и единственный сервер Exchange в компании.

Прямо сейчас мы можем использовать эти новые учетные записи с OWA, но не можем использовать их с Outlook (2002 / XP, извините), так как имена не будут разрешены, потому что их нет в адресной книге. Есть ли предложения, которые я могу проверить, прежде чем прибегать к полной перестройке сервера?

Проблема решена

После долгого расследования с использованием информации из ссылки, предоставленной icky2000, а также множества подобных статей, я обнаружил, что служба обновления получателей работает нормально, но ищет не в том месте.

Запросы LDAP должны были начинаться с чего-то вроде

Searching directory exchange.OURDOMAIN.LOCAL at base 'DC=OURDOMAIN,DC=LOCAL' using filter

но на самом деле начали с

Searching directory exchange.OURDOMAIN.LOCAL at base 'CN=Configuration,DC=OURDOMAIN,DC=LOCAL' using filter.

Используя ADSIedit, я удалил CN=Configuration, часть, и он внезапно начал работать.

Похоже, проблема с Центром отслеживания сообщений не связана и требует дальнейшего изучения. Я подозреваю, что никогда не найду настоящую причину этих проблем, и это меня беспокоит. Тем не менее, на данный момент, по крайней мере, он работает.

Атрибут msExchUserAccountControl должен автоматически устанавливаться службой обновления получателей (RUS). Он также отвечает за установку необходимых атрибутов почтового ящика, чтобы он отображался в глобальном списке адресов. Вероятно, причина, по которой эти новые почтовые ящики не отображаются в глобальном списке адресов (и, следовательно, недоступны для MAPi), заключается в том, что showInAddressBook либо не установлен, либо установлен неправильно. Попытка сравнить этот атрибут у хорошего пользователя с одним из новых. Другая возможность заключается в том, что описанная вами проблема с разрешениями каким-то образом также мешает RUS изменять эти новые почтовые ящики. RUS сложен, и я не могу много разобраться с этим способом, но это, по крайней мере, для вас зацепка. Подробно просмотрите журналы приложений на сервере Exchange и взгляните на это для начала: http://msexchangeteam.com/archive/2004/07/07/175444.aspx. Удачи.